✨ Single/Own Namespace Install Mode Support

[perdasilva]

Description

Part of #593
Closes #1751 and #1752

Adds initial implementation of SingleNamespace and OwnNamespace install mode support for registry+v1 bundle behind SingleOwnNamespaceInstallSupport alpha feature-gate.

The user can install a registry+v1 bundle in SingleNamespace or OwnNamespace install mode by setting the watch namespace through the olm.operatorframework.io/watch-namespace annotation on the ClusterExtension, as long as the following criteria is met:

• bundle supports Single- and/or OwnNamespace install modes
• SingleOwnNamespaceInstallSupport feature-gate is enabled on the controller
• olm.operatorframework.io/watch-namespace annotation points to a single existing namespace

The annotation value will determine the install mode:

• empty: bundle is installed in AllNamespaces mode
• valid namespace name and is equal to the value the install namespace of (.spec.namespace) in the ClusterExtension: bundle is installed in OwnNamespace mode (or SingleNamespace mode if OwnNamespace mode is not supported)
• valid namespace name and the value is not equal to the install namespace (.spec.namespace) in the ClusterExtension: bundle is installed in SingleNamespace mode

Note: SingleNamespace mode also covers the case where the watchNamespace == .spec.namespace. If the operator only supports OwnNamespace install mode, this means it can ONLY watch the install namespace.

If the annotation is not present, standard behavior applies: AllNamespaces mode.
If annotation value is not a valid namespace name the installation will halt with an error.

Notes:

• In order to facilitate testing, I've modified the applier adding the bundleToChart conversion function as a memeber (this way we can mock it). I've only tested the integration of this function into the applier. In a follow up PR mode robust testing will be applier to the conversion package to (further) ensure we're accurately rendering registry+v1 bundles.
• I've also removed the context parameter since it only served to pass a logger that used to log an error when closing the manifest file. To me, it didn't seem worth it. Though I'd be ok with reverting that if there are any objections.

DEMOS

SingleNamespace

OwnNamespace

Reviewer Checklist

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

[netlify]

✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	e39a1f5
🔍 Latest deploy log	https://app.netlify.com/sites/olmv1/deploys/67c05d1cc47d1d0008daecde
😎 Deploy Preview	https://deploy-preview-1724--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.

[codecov]

Codecov Report

Attention: Patch coverage is 88.88889% with 3 lines in your changes missing coverage. Please review.

Project coverage is 68.43%. Comparing base (13a594f) to head (e39a1f5).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/operator-controller/applier/helm.go	70.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1724      +/-   ##
==========================================
+ Coverage   68.39%   68.43%   +0.03%     
==========================================
  Files          62       63       +1     
  Lines        5117     5132      +15     
==========================================
+ Hits         3500     3512      +12     
- Misses       1388     1390       +2     
- Partials      229      230       +1     

Flag	Coverage Δ
e2e	51.55% <51.85%> (-0.15%)	⬇️
unit	56.02% <77.77%> (+0.10%)	⬆️

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]

Wow, I am impressed with how simple that is with the existing code we have.

[LalatenduMohanty]

@joelanford @perdasilva Are we planning to write a RFC for this feature Single own namespace. Also Is this PR related to #593 in some way. In that case, can we update the epic description too.

[camilamacedo86]

/lgtm

[thetechnick]

/lgtm

[pgodowski]

As discussed in the separate venue, @joelanford , there is set of use cases, where it is expected for OLMv1 to allow multiple installation of the same operator with different scopes each, on the same cluster. Just want to make sure this PR is an incremental step towards this and not the final decision.

[joelanford]

OLMv1 won't directly support multi-tenancy as a first class concept. This PR doesn't change that one way or the other. All this PR does is make it possible to install registry+v1 bundles that support Own/SingleNamespace mode, but not AllNamespace mode.

This PR does not preclude multiple installations of the same bundle in different namespaces, so long as the installation of that bundle does not violate OLMv1's single owner policy. One fairly obvious outcome is that bundles that ship CRDs will never be able to be installed twice because CRD names are validated according to their resource name and group. Also of note, the registry+v1 format does not allow for templated names of objects in the bundle, so if a bundle has any cluster-scoped objects, it will only be installable once per cluster. But this is a registry+v1 limitation, not an OLMv1 limitation. In the future, I expect OLMv1 to handle bundle formats that do support arbitrary templating.

I can see how this text makes it seem like we're making a blanket statement about one install per cluster, but that is not technically the case. From a practical perspective, I'm guessing >95% of bundles include a cluster-scoped object, which largely makes this sentence true for end users for now.