-
Notifications
You must be signed in to change notification settings - Fork 24
Qdrant: add helm charts #334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| extraVolumeMounts: {} | ||
| extraVolumes: {} | ||
| # -- PVC Storage Request for `qdrant` data volume | ||
| storageSize: 100Gi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How difficult is it to increase the size of a PVC?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like we allow volume expansion by default, but I'm honestly not sure what the ramificaitons are. 100Gi is large enough for a large chunk of customers, but certainly not all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cloud prefers to start small and scale up as needed (scaling up is easy and we have monitoring for it)
| # -- Docker image name for the `embeddings` image | ||
| name: "qdrant" | ||
| # -- Docker image tag for the `embeddings` image | ||
| defaultTag: "239247_2023-08-18_5.1-433e1b1c997f@sha256:eafcd7af2aca699fa9c9ce8e6aa674cc0470441f794baf031296d5d1cdadd0bc" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pointing to the latest build from main. Should be updated at release.
|
|
||
| qdrant: | ||
| # -- Enable `qdrant` | ||
| enabled: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Disabled by default, just like embeddings
| performance: | ||
| max_optimization_threads: 4 | ||
| optimizers: | ||
| max_optimization_threads: 4 | ||
| mmap_threshold_kb: 1 | ||
| indexing_threshold_kb: 0 | ||
| hnsw_index: | ||
| m: 8 | ||
| ef_construct: 100 | ||
| full_scan_threshold: 10 | ||
| max_indexing_threads: 4 | ||
| on_disk: true | ||
| payload_m: 8 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will probably pull these out to make them configurable, but they are just default values that can be overridden on collection creation which is handled in the application.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's add a note in the manifest and say they're basically unused
| sourcegraph.prometheus/scrape: "true" | ||
| prometheus.io/port: "6333" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested that these populate metrics in Grafana. I'll need to add a basic dashboard for qdrant
| # -- Docker image tag for the `embeddings` image | ||
| defaultTag: "5.1.6@sha256:e849f52e38637882e5d2ba3d7d27a656d897c4b4e2905e1fdb843536d9c948ab" | ||
| # -- Resource requests & limits for the `worker` container, | ||
| # -- Resource requests & limits for the `embeddings` container, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unrelated, just fixing a couple of typos
| limits: | ||
| cpu: "2" | ||
| memory: 8G | ||
| requests: | ||
| cpu: "500m" | ||
| memory: 2G |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there any guidelines for sizing on cloud, other than just "whatever is needed for perf"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in cloud, we will provide our own override.
- https://github.com/sourcegraph/cloud/blob/main/overrides/global.override.yaml
- https://github.com/sourcegraph/cloud/blob/main/overrides/small-resources.override.yaml
generally start small and increase as needed
what you put as default here would serve as the recommendation for on-prem customer, not cloud
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
got it, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall lgtm
question to @camdencheek
- qdrant seems to support cluster mode. how does it work? do we need it to support higher traffic? it's okay to say this out of the scope for MVP.
question to @sourcegraph/team-release
- how do we decide whether to use an upstream chart or roll our own? https://github.com/qdrant/qdrant-helm/
| debug: true | ||
| log_level: INFO | ||
| storage: | ||
| storage_path: /data | ||
| snapshots_path: /data/storage | ||
| on_disk_payload: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these seem to be global flags; we should parameterize them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to parameterize them even if we don't want them to be configurable? We control the volume mount location as well, so I can't think of any reason to move the storage path elsewhere
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
at least debug should be configurable, no?
I'm not sure the implication of debug: true means for qdrant, but we can only expose some of the fields here, e.g., debug and log_level
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oooh, gotcha, yeah definitely. No idea why my eyes focused on just the storage path 😂
I don't think we'll need cluster mode. A single pod with 32GB memory and 4 cores was able to handle sourcegraph.com-level size and traffic in my tests. Most of the scaling benefit comes from being able to build an index rather than horizontal scaling. It's possible that we'll want to support cluster mode in the future, but a single pod should be plenty for the MVP (and beyond). |
Oh, I kinda assumed that our chart shouldn't have dependencies and that we'd want to follow the same patterns across all our services. I guess that wasn't a clear assumption 😄 |
yeah, that's a question for @sourcegraph/team-release how they want to approach this in the future. but it shoudln't be blocking us from merging this experimental thing. |
Yeah, this is how we've been doing it, so it's fine for now 👍 We're still working things like this over and deciding on the best way forward. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
This implements helm charts to add a Qdrant deployment to our cloud deployments. The intent is to replace the
embeddingsservice entirely and to stop depending on blobstore for embeddings storage.Checklist
Test plan
I ran the cluster locally, ensuring that I can generate and search embeddings with Qdrant.
I tested with the following
override.yaml: