This is not strictly a bug, more of a design choice but I wanted to point this out here for the next person who bumps into it.
We are using kustomize to wrap 3rd party helm charts. This way for example it's easy to add external-secret entry for the qdrant api key or use an existing / dedicated persistent volume and persistent volume claim pair with qdrant.
So something like this.
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: dev
helmCharts:
- name: qdrant
releaseName: qdrant
repo: https://qdrant.to/helm
version: "1.16.2"
valuesFile: values.yaml
resources:
- external-secret.yaml
- pv.yaml
- pvc.yaml
Kustomize already has a bit weird relationship when it comes to helm namespace handling, see for example kubernetes-sigs/kustomize#5566. But this is usually rectified by specifying the namespace inside the helmCharts entry block as well.
This does not work in the case of the qdrant helm chart, as it does not defined namespace entries at all in its templates.
kustomize build --enable-helm [path to folder]
Again, this is not a bug, it's a design choice, but I wanted to point out in case this choice ever gets re-evaluated or someone else also bumps into it. In other words, if this was a totally conscious choice, feel free to just close this issue right away.
This is also not a problem when deploying with ArgoCD as it covers this problem.
Currently our workaround is to move the namespace setting into a patch. Normally we have it as a separate file, but to have a single file example, see the following.
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
helmCharts:
- name: qdrant
releaseName: qdrant
repo: https://qdrant.to/helm
version: "1.16.2"
valuesFile: values.yaml
# qdrant's helm chart does not have namespace entries to override by default, so they need to be added manually
patches:
- patch: |-
- op: add
path: /metadata/namespace
value: raiqon
target:
kind: ".*"
version: ".*"
resources:
- external-secret.yaml
Note, currently kustomize has a helm4 incompatibility on mac, so you need to something --helm-command /opt/homebrew/opt/helm@3/bin/helm.
This is not strictly a bug, more of a design choice but I wanted to point this out here for the next person who bumps into it.
We are using kustomize to wrap 3rd party helm charts. This way for example it's easy to add
external-secretentry for the qdrant api key or use an existing / dedicatedpersistent volumeandpersistent volume claimpair with qdrant.So something like this.
Kustomize already has a bit weird relationship when it comes to helm namespace handling, see for example kubernetes-sigs/kustomize#5566. But this is usually rectified by specifying the
namespaceinside thehelmChartsentry block as well.This does not work in the case of the qdrant helm chart, as it does not defined namespace entries at all in its templates.
kustomize build --enable-helm [path to folder]Again, this is not a bug, it's a design choice, but I wanted to point out in case this choice ever gets re-evaluated or someone else also bumps into it. In other words, if this was a totally conscious choice, feel free to just close this issue right away.
This is also not a problem when deploying with ArgoCD as it covers this problem.
Currently our workaround is to move the namespace setting into a patch. Normally we have it as a separate file, but to have a single file example, see the following.
Note, currently kustomize has a helm4 incompatibility on mac, so you need to something
--helm-command /opt/homebrew/opt/helm@3/bin/helm.