Installing a helm release from single K8s manifest YAML file hosted somewhere (e.g. OperatorHub)

[kevin-lindsay-1]

With the rise of https://operatorhub.io/, it would be really nice to be able to declaratively state which operators are needed for a given chart.

[antaloala]

@kevin-lindsay-1 do you mean handling operators packaged in the way OLM framework can handle them? (i.e providing the OLM required staff: CSV manifest, etc.)
I do not really see how that relates to helmfile. It is possible (I actually do like that) to package an operator using one or two helm charts; I prefer two (due to current helm3 limitations on handling the whole LCM of a custom resource, nowadays limited to installation support): one for CRDs manifests and another one for the custom controller related manifests and so using helmfile to install things in the desired order (i.e. CRDs helm chart wrapped in its own (sub)helmfile referred from the "main" helmfile manifest that also list the custom controller Helm chart in the releases stanza).
An OLM packaged operator is not based on Helm charts (that was a decission from CoreOS/RedHat when created it).

[kevin-lindsay-1]

I would basically just run a kubectl create on a particular yaml from operatorhub or the like.

It technically wouldn't invoke helm, but for certain charts an operator being installed is assumed. Since helmfile's overall purpose is in my opinion to improve the DX of helm by adding useful features, I would say that adding operators would also be useful.

If there's a good generic way to wrap that operator into a chart, perhaps that would be ideal, but for something like an external chart, being able to say that it depends on an operator would be necessary. Part of the reason why I like helmfile so much is because it centralizes things into effectively one command, so that local development and CI can use the same helmfile, with near-zero additional steps.

It might be necessary to either state that an operator should be torn down with the helmfile, track dependencies (as in, track which releases need which operators, which seems a bit much), or bundle the operator into the chart in some way.

I have no real preference on implementation, only that it would be a really nice feature for helmfile to be able to define the operator, as well, in order to keep a single source of truth as much as possible.

[mumoshu]

@kevin-lindsay-1 Hey! Honestly speaking I have no experience with operatorhub. Can I safely assume that every operator distributed by operatorhub can be installed with a single YAML file located at https://operatorhub.io/install/${OPERATOR_NAME}.yaml, right?

If so, I think this is a good chance to enhance something we already have- our go-git integration that is already serving you to download git-hosted helm chart or a directory of manifests/kustomize, and our chartify integration that turns maniefsts/kustomize it into a temporary helm chart on install.

In nutshell Helmfile is only able to turn a directory of manifests/kustomize hosted in a git repository into a temp chart today:

releases:
- name: myapp
  chart: git::https://github.com/example/somerepo.git@path/to/dir

In other words, it's unable to handle a single remote YAML file. It's also unable to handle YAML files in a standard HTTP(s) server. Probably extending it to allow both enables us to write something like:

releases:
- name: myoperator
  chart: https://operatorhub.io/install/${OPERATOR_NAME}.yaml
- name: myapp
  chart: ./somechart
  needs:
  - myoperator

WDYT?

[kevin-lindsay-1]

@mumoshu Yes, as far as I am aware it's just a YAML file, and that's the only procedure via OperatorHub.

Looking at how to create, preview, etc. on their website I have found no indication that this pattern would ever use anything other than a single YAML.

During my digging, I found a fairly in-depth reference

---

I like the simple syntax, however I'm not partial to the usage of the word chart, because if you look at an example YAML it is just a single resource that you would potentially put into a chart, but not a chart in and of itself.

[mumoshu]

@kevin-lindsay-1 My quibble is that chart in helmflie.yaml means that treat it a chart that can be installed with helm anyway 😃 Well, I can see your point.

What if it was manifest?

A secret of Helmfile.yaml is that it already supports directory as the alias to chart, which I added because I thought it would better aligh with a directory of K8s manifests and kustomize configs when you use it.

So, adding another alias manifest shoulnd't be a too big adventure from what we have today...

[kevin-lindsay-1]

@mumoshu Manifest or resource or something works for me, as long as the "needs" behavior works as intended.

From a timing standpoint, I'm not sure if adding an operator manifest immediately registers the CRDs, so it might need some kind of wait condition.

[mumoshu]

@kevin-lindsay-1 Hey! Thanks for confirming.

From a timing standpoint, I'm not sure if adding an operator manifest immediately registers the CRDs, so it might need some kind of wait condition.

Im not sure either. Perhaps there're potentially three kinds of operators, one that includes CRD in their manifest, other that automatically installs CRDs on startup, and another that requires you to install CRDs beforehand?

Helmfile handles the first kind without issues, except that you'll occasionally required to write disableValidation: false to helmfile-diff to not fail on trying to diff custom resources for CRDs that aren't installed onto the cluster yet.

Helmfile should also handle the third kind gracefully with needs.

[mumoshu]

// Linking #1757 as a related issue

[mumoshu]

Well, I'm not yet sure if this is a showstopper. But I'd happily review it if you contribute the feature outlined above by myself.