Allow set install namespace for OLM deployable test

[sxd]

Is your feature request related to a problem? Please describe.

I've been trying to incorporate the preflight check operator into our pipeline to avoid issues during the final certification period, the big problem that I have faced is that it requires an OpenShift cluster, this it's perfect, but spinning a cluster every time that we need to check the CI it's a lot of time wasted on this, but I was thinking on running this test against an already running OpenShift cluster, but when running two test in parallel conflicts due to preflight using the package name as the target namespace to install the operator here https://github.com/redhat-openshift-ecosystem/openshift-preflight/blob/main/internal/policy/operator/deployable_by_olm.go#L313

Describe the solution you'd like.

I've been browsing the code and thinking on adding this as an option to the preflight run and replace the value here https://github.com/redhat-openshift-ecosystem/openshift-preflight/blob/main/internal/policy/operator/deployable_by_olm.go#L313 and avoid using the appName as the namespace.

In short, a new variable to specify the namespace to test the operator install process will be amazing.

Describe alternatives you've considered.

There's a variable PFLT_NAMESPACE and argument --namespace that contains the namespace for the scorecard, probably we can use the same one to use only one namespace for everything ?

Additional context.

This will be really useful to run multiple checks in one cluster and also to trigger operator-pipeline multiple times in the same cluster which is my ultimate goal

[acornett21]

Hi @sxd I'm not sure if propagating the --namespace flag to DeployableByOLM would solve your issue of concurrency, I think what would happen is that one operator in one namespace would pass, and the other would fail because OLM would block the duplicate operator name from being installed.

I know spinning up clusters is time consuming, preflight doesn't really need a full multi-node cluster to run, since we are only checking the operator install, and not functionally testing the operator. CRC (OpenShift Local) might be an option to use in CI before you run operator-pipeline in a full cluster, I know other operator authors are using CRC in CI.

We'll try to look at the feasibility of this feature and circle back.

[bcrochet]

I'd be more inclined to add a random suffix to the namespace rather than propagate the namespace flag and overload its usage. Which would also solve a potential problem of having a failed run, and the namespace being in an inconsistent state.

[sxd]

Hi @acornett21

Well it will since the operator will be installed in a different namespace right? Since that it's supported in CloudNativePG, but if you tell me it's not going to work a multi-namespace operator install for the testing I trust.

Yeah I already look into CRC but was long time ago, I haven't check if has improve it in terms of resource consumption (I'm running stuff on github runners so resources are really limited) but will for sure look into this.

If you can try and look that will be amazing!!

[sxd]

I'd be more inclined to add a random suffix to the namespace rather than propagate the namespace flag and overload its usage. Which would also solve a potential problem of having a failed run, and the namespace being in an inconsistent state.

Hi @bcrochet

Well, a random suffix will work more than perfectly! Didn't thought on that idea, we actually use a random namespace to create the operator pipeline and works perfectly! Thank you for that idea!

[acornett21]

@sxd I was thinking of AllNamespaces install mode, when thinking about this and that causing failures. Since preflight determines the InstallMode

openshift-preflight/internal/policy/operator/deployable_by_olm.go

Lines 437 to 446 in 7dcb0d8

	switch installMode {
	case operatorsv1alpha1.InstallModeTypeOwnNamespace:
	targetNamespaces = []string{operatorData.InstallNamespace}
	case operatorsv1alpha1.InstallModeTypeSingleNamespace:
	targetNamespaces = []string{operatorData.TargetNamespace}
	case operatorsv1alpha1.InstallModeTypeMultiNamespace:
	targetNamespaces = []string{operatorData.TargetNamespace, operatorData.InstallNamespace}
	case operatorsv1alpha1.InstallModeTypeAllNamespaces:
	targetNamespaces = []string{}
	}

and your operator supporting multiple install modes, OwnNamespace would get selected, which uses operatorData.InstallNamespace, so multiple installs would be possible.

Since preflight needs to determine the namespace(s) to look at based on the supported InstallModes defined in the CSV, I don't think exposing a flag makes sense (this could lead to false positives/negatives), since we've seen operator authors not understand how to setup these values properly.

@bcrochet's Idea about a random suffix seems like it would work for your use case, however if we implement this we need to do the following:

• Add support for InstallNamespace
• Add support for TargetNamespace
• Use the k8s random function so the namespaces are DNS-1123 compliant. rand.String(5) would make sense, as this is the suffix length for pods
• Test and make sure this solves the concurrency issue (The below values should work, we might want to test an operator that only supports MultiNamespace as well)
  • PFLT_INDEXIMAGE=registry.redhat.io/redhat/certified-operator-index:v4.20
  • preflight check operator registry.connect.redhat.com/enterprisedb/cloud-native-postgresql@sha256:16384249d49258831634aa3535f97906f41ebbf92d2f28bf6645e416ec3da96e
• Document (inline or otherwise) that this won't support currency for operators that only support AllNamespaces. I think all of the other InstallModes would be supported with this though.
  • Maybe just stating this here is enough?

[sxd]

Hi @acornett21

Sorry for the late answer I missed this! yes that's actually the case, the problem is that it will use it to install in the same namespace two times, and that leads to conflicts when detecting the operator to be running or not, so in theory it should work, in the practices, it doesn't :(.

I'm a bit lost here, what do you think we should try now?

Regards!