Related to #943 which is no longer going to happen since ksonnet may stop development.
We currently manage kubernetes manifests using https://github.com/ksonnet/kubecfg and jsonnet.
Whilst ksonnet itself may no longer be supported (unless it gets new maintainers!), kubecfg will still be maintained. The lack of development on ksonnet itself, may see people moving towards kubecfg/jsonnet (since it's a relatively easy transition).
It would be great if there was some generic hook that we could use to pre-process configs into kubernetes manifests. In the case of kubecfg, it will typically involve performing kubecfg validate and kubecfg show on each jsonnet file, which in turn generates the k8s yaml.
It looks like the design proposal referenced in #1261 would also resolve this :)
Please take a look at https://docs.google.com/document/d/1ebAjaZF84G3RINYvw8ii6dO4-_zO645j8Hb7mvrPKPY/edit?usp=drivesdk
I plan to create a proof of concept based on that draft
Please take a look at https://docs.google.com/document/d/1ebAjaZF84G3RINYvw8ii6dO4-_zO645j8Hb7mvrPKPY/edit?usp=drivesdk
I plan to create a proof of concept based on that draft
I favor this approach, because it is generic enough to allow any kind of configuration solution. This needs to be stressed, the ecosystem is changing to rapidly at the moment to lock to a single one
Covered by #943
Alright, kubecfg is the project, let's leave this one open
I have a working solution and an example for using Kustomize, see https://github.com/2opremio/flux-kustomize-demo which most probably can be adapted to use kubecfg.
Please take a look, if the feedback is positive we will end up merging it.
Any update on that?
There is already support for it through .flux.yaml files. See https://docs.fluxcd.io/en/latest/references/fluxyaml-config-files.html
The only catch is that you need to install the kubecfg & jsonnet executables/runtime dependencies yourselves since they are not included in the Flux image (this can be done by creating your own image or installing the dependencies through an init container).
And with this, I am going to close this ticket.
Most helpful comment
I favor this approach, because it is generic enough to allow any kind of configuration solution. This needs to be stressed, the ecosystem is changing to rapidly at the moment to lock to a single one