ability to use list of objects in objecttemplate

[elee1766]

it would be very useful if i could do something like

matrix:
- name: inputs
  objects:
    matches:
      apiVersion: v1
      kind: SomeResource
      namespace: default
      selector:
        "some/label": "yay"

and then the matrix would have each matching object in an array as the input

the reason is - i would like to use a template combined with my own crd to deploy sets of resources. the template-operator in this way can act like a generic operator, which is very cool.

happy to contribute if yall think it would be a good idea

[codablock]

This feature makes total sense, yes. I'm happy to see contributions.

I would suggest to align this with what Kluctl already supports here. This is implemented here.

To be honest, I even consider merging the efforts of the kluctl-controller with the template-controller since quite some time already. Right now, most of the things possible in the template-controller are already possible in Kluctl, with the big disadvantage that you need a full-blown Kluctl deployment project to replicate what the template-controller does.

I'm considering changing the KluctlDeployment CRD to also support inline-templates, without the need to put these templates into a Git repo.

If you're open to contributions, would you be willing to investigate into Kluctl as well and see if that's maybe the better place to continue such efforts? If not, I'm also perfectly fine with this specific feature (labels) being implemented in template-controller.

[elee1766]

awesome!

since template-controller already imports kluctl, i think it makes a lot of sense to just import and share the behavior. let me try to create a PR - are you using kind or k3d to test ? is there a config somewhere i should be using ?

we use flux as our primary gitops, and it has a lot of features kluctl is missing. template-controller is great because it fills the feature that our flux is missing, that is, merge request deploys. I would be very sad if template-controller required a full deployment of kluctl gitops. I do understand that the cost to maintain it not free, so perhaps moving to change template-controller more into something of a light-weight wrapper on top of the kluctl package is a good idea as it would reduce the maintenance load.

a piece of perhaps relevant feedback @codablock, re I'm considering changing the KluctlDeployment CRD to also support inline-templates, without the need to put these templates into a Git repo.

ultimately i plan to create helm-releases from my CRD using the ObjectTemplate, instead of creating a git template. the reason is because i don't feel comfortable using jinja2 to produce a large amount of resources. our company has lots of experience managing helm deployments and writing helm charts, and so it makes a lot more sense for us to use small amounts of jinja2 to write the values.yaml and then let a helm controller handle the rest

as a result, i do believe it makes a lot of sense for the kluctldeployment crd to deploy inline templates, as a use case i believe will be to transform a resource using jinja2 to helm chart values.

[codablock]

the kluctl-controller is as lightweight as the template-controller when it comes to installation. There is really only the controller and RBAC that is needed. There also was a Helm Chart in the past for it (right now, you use kluctl to install the controller) and I'd need to reintroduce that chart for people who want to use kluctl-controller just for ObjectTemplate like use-cases. The thing that makes it more complicated is the nature of Kluctl deployment projects, which require the KluctlDeployment to point to a Git repository right now...this is something that I'd make easier then.

I wonder, which feature do you think are missing in Kluctl that Flux offers? Not trying to convince you, just interested in what needs to be improved :)

[elee1766]

one big feature we use is the webhooks. https://fluxcd.io/flux/guides/webhook-receivers/ .

flux has a lot better separation. (repository crd, kustomization crd, helmrelease crd), while you have them all combined into KluctlDeployment. that separation is really useful, helmrelease especially.

needing to use a custom template format that isn't a k8s resource/kustomize is a big missing feature. flux having everything be a crd is really great.

finally, flux is a lot better documented.

[codablock]

Thanks for the feedback, it helps me a lot to understand the space.

one big feature we use is the webhooks. https://fluxcd.io/flux/guides/webhook-receivers/ .

Webhooks are definitely planned, but currently with low priority as people can just use shorter reconciliation intervals for now. Kluctl uses some advanced Git caching under the hood, making short intervals cheaper, even for larger repos.

flux has a lot better separation. (repository crd, kustomization crd, helmrelease crd), while you have them all combined into KluctlDeployment. that separation is really useful, helmrelease especially.

TBH, this was one of the largest turn-downs for me when looking at Flux as it brings in the largest down-side of Flux, which is complete dependence on CRD based GitOps. It makes testing nested changes very difficult because you can't dry-run the cascade of CRs easily. But I also know that this opinion (I generally believe that CRDs are being overused) is not broadly shared in the K8s space :)

needing to use a custom template format that isn't a k8s resource/kustomize is a big missing feature. flux having everything be a crd is really great.

Kluctl uses Kustomize under the hood. Templating is put on top and doesn't have to be used extensively.

finally, flux is a lot better documented.

That is 100% true :D This will need to get improved in Kluctl.

Also, Flux has much better adoption, making it much easier to find info and get help online. Finding hires with experience is also a lot easier. In the end, people must have very good reasons to switch to a solution like Kluctl, and feedback helps me to figure out how to formulate these reasons.

[elee1766]

@codablock have been thinking about this conversation

But I also know that this opinion (I generally believe that CRDs are being overused) is not broadly shared in the K8s space :)

yes - i notice that your solution is an attempt to have a single crd to reflect many different possible things, and have the more complicated logic be done by the template.

the kluctl-controller is as lightweight as the template-controller when it comes to installation. There is really only the controller and RBAC that is needed. There also was a Helm Chart in the past for it (right now, you use kluctl to install the controller) and I'd need to reintroduce that chart for people who want to use kluctl-controller just for ObjectTemplate like use-cases. The thing that makes it more complicated is the nature of Kluctl deployment projects, which require the KluctlDeployment to point to a Git repository right now...this is something that I'd make easier then.

thinking more about the maintainence work for you - maybe it does make more sense to merge in the objecttemplate and git merge requests features from template-controller to kluctl.

personally, i don't think that kluctl is mutually exclusive with flux. I can easily see either app being launched in a "flux-controller" mode that could consume flux sourceRefs as git repositories and have flux trigger its reconciles. if kluctldeployment can point at a sourceref and reconcile on sourceref reconcile, that's actually preferable to us as workflow to declare the templates as separate files not in the crd.

flux controllers are already one controller->one crd, so its kind of a good fit.

sharing the GitRepository sourceRef which sends reconciliation requests up the chain is really nice in a push based workflow.

we use template-controller every day to manage preview deploys of our apps - it would be really cool if we could use our already-configured flux webhooks to force reconciliations on branch push.