The next iteration of WDQS (migration to the new backend) is planned around an idea from @BTullis:
- We add a kubelet to our existing wdqs nodes and add them to the dse-k8s cluster
- We add a host **taint** so that regular workloads are not scheduled on these wdqs nodes.
- We deploy qlever to these hosts using kubernetes, with a specific **toleration** so that it selects only the wdqs db nodes.
- In this way, our wdqs db nodes become **dedicated kubernetes worker nodes**, instead of being dedicated bare-metal nodes.
- In addition to this, we make the **local storage** on the wdqs nodes available to use as Kubernetes Volumes.
- This means that we would not be compromising on I/O performance by moving WDQS to Kubernetes, as we would if we were to use Ceph volumes.
An important part of this is the deployment of the backend the the consumer via Kubernetes (targetting `DSE`).
AC:
[] Helm chart for `wdqs-qlever` and `wdqs-streaming-consumer` as a sidecar container
[] Helmfile deployment for the chart which binds replicas to the `wdqs` nodes via `taint` and `toleration` values