Helm chart about etcd-operator HOT 7 CLOSED

Could you please give an example?

Easy.

1. put CRDs in crds catalogue inside chart. Then Helm would be able to install them. The drawback is that Helm does not know how to upgrade CRDs, so FluxCD implemented it's own keyword for upgrading CRDs and solved this issue. Werf project also fixed it. What's going with ArgoCD I don't know. Something like this: aws-controllers-k8s/community#2007 (comment)
2. put CRDs in templates. No idea because it loses the proper semantics.
3. put CRDs in another chart. As I told before - it makes sense, as many vendors do the same. Like linkerd: https://github.com/linkerd/linkerd2/tree/main/charts It allows to install CRDs separately even if you don't need controller or create a separate life-cycle for CRDs (usually they are upgraded more rare than operator itself)
4. put jobs in Helm chart. Probably the worst option. First of all you are losing the semantica of proper apply. Particularly if you use post-job or ArgoCD which does not utilise Helm library and reimplements it's features in it's own way. Second argument against is that you surely will add to operator tolerations/affinity and other technical options. If you are using job you should not copy them from main operator pod, but give the user option to fine tune them. Third, Job is run asynchronously. So it means that it could just create Pod and it would stuck in pending or crashloopback state. Like image for Job is not accesible in air-gap environment. So shortly - you will end with 2x configuration settings in helm chart.
5. just put management of CRDs into controller itself. I wonder why I did not see such an approach. But it looks like that ACK https://github.com/aws-controllers-k8s/community will stick to it. It gives more control and better observability.

Any other ideas? I don't know what to add. But really Helm + CRDs sucks.

from etcd-operator.

My thoughts about the scope of this issue:

1. Support environment variables as a templated map using configMap and envFrom.
2. Put CRDs as pre-install and pre-upgrade helm-hooks, and add a mechanism to put them in automatically with pre-commit.
3. Add auto-generated json-schema using https://github.com/losisin/helm-values-schema-json, add it in pre-commit
4. Add auto-generated documentation using https://github.com/norwoodj/helm-docs, add it in pre-commit
5. Make a pipeline to publish helm chart to the GHCR with auto updated version.

from etcd-operator.

from etcd-operator.

Otherwise you will run into a bunch of corner cases.

@gecube Could you please give an example?

I understand that using crds directory isn't the best idea, but what is the problem with helm hooks?
Rough implementation can be found in this draft.

from etcd-operator.

5. Could you give more details?

@gecube
It's not that special, just a templated map. I've added an example for you.

from etcd-operator.

@gecube
I partially agree with you, and IMO controlling CRDs from the controller itself is the best option overall.

Let's discuss the approach internally, in tg :)

from etcd-operator.

Once more, the scope of this task:

1. Transfer the current kustomize configuration to a simple helm chart.
2. Support environment variables as a templated map using configMap and envFrom in etcdOperator.
3. Put CRDs in directory crds and add documentation about crds upgrade process using kubectl apply
4. Add auto-generated json-schema using https://github.com/losisin/helm-values-schema-json, add it in pre-commit
5. Add auto-generated documentation using https://github.com/norwoodj/helm-docs, add it in pre-commit
6. Make a pipeline to publish helm chart to the GHCR with auto updated version.

from etcd-operator.