⚠ use bundle name and version instead of image in (cluster)extension status

[joelanford]

Description

Rename .status.{installed|resolved}BundleResource to .status.{installed|resolved}Bundle and convert from a string to a struct with {Name string, Version string}

Fixes #270

There are other follow-on improvements we need to think about, that are mentioned in the last few comments of #270:

• What if the installed operator disappears from the catalog?
  • Answer: that should not affect the installed App and should not affect the .status.installedBundle value. But we might update the status with resolution failure issues if that bundle removal causes the extension to longer match anything in the new catalog.
• What if the catalog changes in a way that the existing installed bundle gets new metadata? This would definitely be something we'd recommend against, but as things stand today, there's no mechanism to enforce that bundle metadata doesn't change in a catalog.
  • Answer: We would resolve something from the catalog if the catalog changed. But this answer depends on what changed in the bundle metadata, and what the user specified constraints are. I think the general answer is that if the App spec remains identical, but the name or version changes, that would look like a different bundle to the extension controller and we would end up updating the status with that newly resolved bundle's metadata.
• If/when we get to the point of making the Operator API support installation without dereferencing from a catalog, do we expect to pull this metadata from the bundle? (I think absolutely yes, and this plays into item (2). Ideally the catalog contains just a pointer to a bundle, and it's really the bundle that carries the metadata, not the catalog).
  • Answer: we either figure out how to extract that metadata from the bundle directly, or perhaps we populate the status differently in this case. In both cases, it will be important to distinguish between "this is what is actually installed" vs "this is what I want to be installed"

Reviewer Checklist

• API Go Documentation
• Tests: Unit Tests (and E2E Tests, if appropriate)
• Comprehensive Commit Messages
• Links to related GitHub Issue(s)

[codecov]

Codecov Report

Attention: Patch coverage is 37.50000% with 40 lines in your changes are missing coverage. Please review.

Project coverage is 63.50%. Comparing base (d10056e) to head (252cb87).
Report is 7 commits behind head on main.

Files	Patch %	Lines
internal/controllers/extension_controller.go	20.83%	17 Missing and 2 partials ⚠️
api/v1alpha1/zz_generated.deepcopy.go	33.33%	16 Missing ⚠️
...nternal/controllers/clusterextension_controller.go	68.75%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #679      +/-   ##
==========================================
- Coverage   64.01%   63.50%   -0.51%     
==========================================
  Files          22       22              
  Lines        1370     1403      +33     
==========================================
+ Hits          877      891      +14     
- Misses        442      459      +17     
- Partials       51       53       +2     

Flag	Coverage Δ
e2e	47.25% <35.93%> (-0.12%)	⬇️
unit	57.40% <25.00%> (-1.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[joelanford]

Looks like an issue with the Go version used by our Tilt setup:

Hopefully fixed here: operator-framework/tilt-support#6

[varshaprasad96]

Thanks for the PR, Joe! Just a small nit.
/lgtm
/approve

Two more follow ups, which we need not address right away and is for future:

1. Both Installed and Resolved Bundle can be an array - this may make more sense when we support direct installation from multiple sources. Thinking it from SRE needs, where they would like to augment the operator bundle, with say a telemetry/monitoring stack which is a part of separate bundle but the same Extension entity.
2. Can the BundleMetadata also include a type - I know we discussed that its not necessary, but thinking about it again it would make sense if we support direct install with multiple sources, where its not necessary that all the contents are from the same version of the bundle. Even if the bundle is same, source could be different - given there is no resolution, bundle uniqueness need not necessarily be followed.

This is again assuming that we extract the version from the bundle, and will continue populating similar to how we do with resolution.

Supporting multiple installations is not a concern for now, and can be handled when we implement that feature.

[varshaprasad96]

Nit: though bundle cannot be nil after resolution (we must already be having a check for it before), can a check also be added here to avoid nil pointer errors.

[joelanford]

I was thinking about this as well. If we pass a nil pointer into this function, what is our expectation?

1. We could panic on the basis that we always expect to pass a non-nil pointer and a panic is an indication of a programmer error. I could see making that more explicit by checking for nil and panicking with a custom message.
2. We could return an error from this function, but then we have to consider what we'd want the caller to do with it. It doesn't seem all that great to just return that error up the stack.
3. We could return a nil BundleMetadata, which seems fairly reasonable. At that point, we could call it essentially everywhere that we set InstalledBundle or ResolvedBundle.

I'm between 1 and 3. WDYT?

[everettraven]

I'm leaning towards 3 personally. I think it makes logical sense that if a nil value is provided as an input to this function it returns a nil response because if there is no bundle there can be no bundle metadata.

In addition to whichever approach is taken, could we also add a comment to document the expected behavior of this function?

[grokspawn]

My concern (re: option 3) would be side-effects if nil is not handled properly in all callers of this function. If we document that this produces nil for nil input, then it behooves the caller to handle properly. If undocumented, I think this is this function's responsibility to impose sanity (so option 1).

[varshaprasad96]

Leaning towards option (1) too, given this is going to be internal, and could only be a programmer's error when they expect a bundle to be not nil, and it ends up being so - as in the previous instances we are explicitly setting the installedResource to be nil.

To maintain consistency, we could follow (1) do a check and panic if its nil, or follow (3) not explicitly set nil everywhere else, instead call this function.

[joelanford]

I'll go with option (1):

• Add an explicit panic, so that it is clear to our future selves what the intent is
• Add a comment on the function signature that describes the expectations/behavior.

[everettraven]

Can we make this change on the ClusterExtension API without it being considered a breaking change to the resultant CRD?

I can see an argument for not being concerned about this, but I know in the past we've talked about trying to adhere to CRD versioning standards even though we are in a v0/alpha state with this project where by semver breaking changes are allowed to happen. Is adhering to the idea of not making breaking changes to a CRD still something we want to focus on moving forward?

As an aside, I don't see this as a problem for the Extension API as I don't think we have cut a release with that API available yet.

[joelanford]

We could if we had to. We could add this field and deprecate the old one. I don't think it's worth it to go to the trouble in an alpha API that we'll likely drop in the next couple of months.

I suppose you could argue, "why make the change at all if we're planning to remove the API?". I'd say that:

1. ClusterExtension is still more mature, so making this change there is essentially a preview for existing users of ClusterExtension
2. It's easier, at least in this case, to keep ClusterExtension and Extension functionality aligned in the areas where there is no fundamental difference between the two.

[everettraven]

I don't think it's worth it to go to the trouble in an alpha API that we'll likely drop in the next couple of months

Totally fair. I just wanted to explicitly call this out to make sure that we were making this breaking change as a conscious decision since we have intentionally tried to avoid those in the past, even on our alpha APIs.

I do think in general, we should err on the side of not making breaking changes due to potential side effect to the cluster/clients but I do understand that it should be okay since we are in an alpha state both as a project and for the APIs.

[openshift-ci]

New changes are detected. LGTM label has been removed.

[joelanford]

Holding until #683 merges.

[netlify]

✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	e5f35f2
🔍 Latest deploy log	https://app.netlify.com/sites/olmv1/deploys/660488b21800be0008ddb533
😎 Deploy Preview	https://deploy-preview-679--olmv1.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[joelanford]

I chatted with @ankitathomas and she suggested moving ahead with this because she is tied up on other issues and can rebase #683 after this merges.