Today, if the Operator is using a single-namespace or own-namesapce mode, the namespace is already defined in the bundle-registry-v1 as an environment variable (e.g., falcon-operator).

• Could we not simply retrieve the ENV VAR and use it in those modes instead of need a new annotation? Why do we need a new annotation?
• Do we need the annotation because we want to allow users to switch between modes dynamically?

I'm not sure that's necessarily a single-/own-namespace specific thing. I think it's how operators are configured for one install mode or another (i.e. when OLMv0 stamps out the deployments it will set that ENV VAR to the value of the namespace's operatorgroup's target namespaces. set the olm.targetNamespaces annotation to the value in the namespace's OperatorGroup)

What I think we may want to think about in the next iteration is verifying that the bundle supports the requested install mode. (edit: I think it's already the case anyway [ref])

For the second point: in a way, yes. But the way to frame it is that we're treating this as a kind of an install-time configuration and don't want to necessarily block the user from doing it. I still think this needs extra discussion, since allowing configuration change at the API level != the runtime allowing the installation to continue with a given configuration (and the check may or may not take into account the current state of the installation and the runtime may or may not allow a new configuration through depending on the current state of the operator). I think this will be explored more in-depth when we RFC the API changes.

Some more info on install modes and targetNamespaces (https://olm.operatorframework.io/docs/advanced-tasks/operator-scoping-with-operatorgroups/#targetnamespaces-and-their-relationship-to-installmodes)

That's what I thought. Couldn't this be handled by the feature gate, where we perform the support check?

• If the feature is enabled, it sets the namespace and doesn’t return an error.
• If not, it continues working as it does today.

I do not remember it anymore, how we deal with it in OLMV0
When we change in the console the target namespace do we update the CSV?

But the watch namespace is a parameter for the user to choose. I don't quite understand the suggestion. You might be thinking about the default (or suggested) namespace. That's some metadata on the CSV that can be used by console as the value for the install namespace to save the user having to input something. But, the user can still set the value.

In v0 to install an operator you need to:

1. create the (install) Namespace
2. create the OperatorGroup
3. create the Subscription

The console basically automates those steps and uses the default namespace by default.

The OperatorGroup's .spec.targetNamespaces will then go into the olm.targetNamespaces annotation on the controller pod. The env var is then set using the downward api.

My guess is that the console also gives you different installation options depending on the install mode support. If you want to install it in SingleNamespace, you'll need to name the namespace (not sure if the console will also create it if it doesn't exist - I'd say so though). If the user wants OwnNamespace, then console will use the install namespace. If AllNamespace, then it will leave .spec.targetNamespace empty. If MultiNamespaces, then the user will probably have to enter in a list (or select from the list of existing namespace, I'm not sure).

The point is, both install and watch (or target) namespace(s) are user inputs. Does that help clarify everything?

If we do not modify this part of the code, then I understand that:

• If we continue using the same index that includes multiple operators targeting SingleNamespace or OwnNamespace modes,
• And I attempt to install those operators, they will fail,
• The current workaround would be to manually add the annotation in the Extension to make it work.

Given this, I believe we also need to modify this validation, right?
We should introduce a change that allows support for both SingleNamespace and OwnNamespace modes, gated under a feature flag to ensure compatibility something like:

func validateTargetNamespaces(supportedInstallModes sets.Set[string], installNamespace string, targetNamespaces []string) error {
	set := sets.New[string](targetNamespaces...)
	switch {
	case set.Len() == 0 || (set.Len() == 1 && set.Has("")):
		// Default behavior: Only supports InstallModeTypeAllNamespaces
		if supportedInstallModes.Has(string(v1alpha1.InstallModeTypeAllNamespaces)) {
			return nil
		}

		// Allow SingleNamespace and OwnNamespace if the feature flag is enabled
		if features.OperatorControllerFeatureGate.Enabled(features.SingleOwnNamespaceInstallSupport) {
			if supportedInstallModes.Has(string(v1alpha1.InstallModeTypeSingleNamespace)) ||
				supportedInstallModes.Has(string(v1alpha1.InstallModeTypeOwnNamespace)) {
				return nil
			}
		}

		return fmt.Errorf("supported install modes %v do not support targeting all namespaces", sets.List(supportedInstallModes))

....
}

Could we change it now OR do we need to change the API?

👍 I see what you're doing here.

We now call RegistryV1ToHelmChart to handle the conversion and set it in the structure.
Then, after the check/convention, we override the watch namespace based on the annotation.

However, if the CVS is set to single namespace or own namespace, the bundle will still fail, right?
We're only allowing the switch to single/own namespace at runtime via the feature flag, but we still cannot manage/applying a bundle when the CVS is explicitly set to single/own namespace.

The install mode validation is based on the install and watch namespace inputs. If the user tries to install in SingleNamespace mode but only OwnNamespace mode is supported, validation will fail.

The logic is:

1. take registry+v1 bundle filesystem (with CSV and all other bundle resources), install namespace, and watch namespace
2. generate a RegistryV1 representation
3. feed that to Convert along with the install and watch namespace. This method generates all the plain manifest resources needed to install the bundle in the install namespace and watching the given install namespace ("" -> watch all namespaces). This includes parsing the CSV into the controller deployment(s), service account(s), and RBAC scoped depending on the install mode. This method also does all the validation to ensure that the install mode is supported by the bundle, and that it doesn't include any (currently) unsupported resources (e.g. Webhooks).
4. the set of plain manifests is transformed into a Helm Chart
5. Helm Chart is installed/upgraded.

The Apply method doesn't have any concept of watch namespaces. It just takes the ClusterExtension. Right now, we take the watch namespace input from the annotation. In the near future we'll take it directly from the ClusterExtension spec.

The CSV isn't set to one install mode or another. It just declares which install modes it supports. The value of watch namespace is what decides the install mode at install time. Does that make sense?

Can we add a test here to ensure that if it is a MultiNamespace, it fails when the flag is enabled?
I think we also need add the validation to fail on this case right?

Should not those still fail when the flag is not used and only work when the feature flag is used?