search

operator-framework / operator-controller

A new and improved management framework for extending Kubernetes with Operators
Apache License 2.0
45 stars 52 forks source link

Support for non-image bundle types #458

Open m1kola opened 11 months ago

m1kola commented 11 months ago

There are several places where we rely on bundle being an image. With the plan to support more types (such as git repos) we need to refactor operator controller to not assume image type.

Here are a few places where this is happening at the moment:

https://github.com/operator-framework/operator-controller/blob/e001a0f6ffd62fc478148463ad9b39a7b2e404a3/internal/controllers/operator_controller.go#L287-L291

https://github.com/operator-framework/operator-controller/blob/e001a0f6ffd62fc478148463ad9b39a7b2e404a3/internal/resolution/variablesources/bundle_deployment.go#L41

m1kola commented 11 months ago

For identifying installed bundle and its successors (currently in BundleDeploymentVariableSource) we can do something like below:

  1. For BundleDeployments with Installed=True condition, compute a digest of its .Spec.Template.Spec.Source.
  2. When looking at bundles in the catalog, we figure out what the .Spec.Template.Spec.Source would be if we were to select that bundle, and compute that digest.
  3. If the digests match, we look for successors of item (2) in the catalog and add all of them to our successors list

This will make the process to not rely on a specific source type.

@joelanford please let me know if I captured it incorrectly

joelanford commented 11 months ago

Yeah, I think this sounds correct. I know that @varshaprasad96's rukpak v1alpha2 work is going to change this to an extent.

Also, I think we're headed in a direction where the catalog contains a BundleDeployment.spec (or template of one) that would potentially simplify this. Operator controller would no longer have to derive a BD. It would just have it from the catalog.