CRD arangomember is deployed by both charts: kube-arangodb and kube-arangodb-crd
The CRD arangomember is deployed by both charts: kube-arangodb and kube-arangodb-crd
=> the last chart wins
I would suggest that only the chart kube-arangodb-crd create CRDs.
Hello!
We want to include CRD creation into kube-arangodb chart into crds section. It is recommended by Helm3 right now.
It was first step for migration, we will move other charts under kube-arangodb.
If order of installation is like described in docs - first kube-arangodb-crd, then kube-arangodb- everything should go fine.kube-arangodb-crdshould install new CRD, after thatkube-arangodb` should be fine that CRD exists. If this statement is wrong we will update flow, but it passed all manual tests.
Best Regards, Adam.
In my opinion it would be better to separate K8S Cluster admin task and K8S namespace admin tasks as they are different concerns:
- cluster admin: creates CRDs, ClusterRoles and ClusterColebinding
- Namespace admin: creates ServiceAccount and ArangoDB operator
Otherwise only a K8S Cluster admin can use the chart
Hello!
We can achieve isolation with this approach - CRD from helm are installed as optional. Currently, it is split like this:
- In
kube-arangodbwe supportnamespacedmode, so it can be installed within namespace (without admin access). You can skip CRD installation by helm command flag (--skip-crds). - CRD can be installed before by system-admin - even using kubectl, helm command - directly from
kube-arangodbchart.
Best Regards, Adam.
Thoughts on adding a helm values to wrap the CRD that can be disabled from the values.yaml? With some CD systems like ArgoCD, we can't pass in command line arguments to helm