check in Qdrant to registry #61
Conversation
There was a problem hiding this comment.
Thanks @TristenHarr
I'll approve so that this gets some more eyes on it for testing prior to release. I pinged @daniel-chambers asking about the config flow since it does seem a little janky, but maybe it's ok. I don't have a strong opinion except for the fact that it requires more tooling to be installed by the user.
| First you'll need to clone [this repo](https://github.com/hasura/ndc-qdrant), and run ```npm install``` | ||
| i. The easiest way to generate a configuration file is to run the generate-config script using ts-node. | ||
|
|
||
| When running this script specify: | ||
|
|
||
| --url The URL where Qdrant is hosted | ||
|
|
||
| --key The API key for connecting to the Qdrant Client. | ||
|
|
||
| --output The name of the file to store the configuration in |
There was a problem hiding this comment.
@daniel-chambers what do you reckon about this workflow instead of running the config server? What's your perspective from having worked with the Dynamo config?
There was a problem hiding this comment.
I think the configuration server is necessary from a tooling perspective. My understanding was that our tooling is envisioned to use configuration servers to do things like:
- Get the configuration schema for the LSP
- Get an empty configuration
- Update the configuration with schema introspection details
- Validate the configuration and display errors
However, I'm not sure how exactly the tooling is supposed to run a configuration server etc... that's why I assumed in my DynamoDB connector docker container that the config server port would be exposed and that you passed the standard command line args to the docker container to start either the main server or the config server.
I'm not against having some other way like this generate-config tool as well, though.
This checks the Qdrant connector into the registry, tagged at v0.1