manifests: OLM is creating a namespace without run-level

[abhinavdahiya]

On installation CVO is errors until openshift-apiserver is running because of missing openshift.io/run-level: "1" label on openshift-operators.

I1212 21:46:09.241861       1 cvo.go:269] Error syncing operator openshift-cluster-version/version: Could not update operatorgroup "openshift-operators/global-operators" (operators.coreos.com/v1alpha2, 108 of 218): the server has forbidden updates to this resource

OLM is running at pretty high priority order (30) in release payload and is blocking installation of other operators for quite some time.

What is the use of openshift-operators namespace and why is this in the release payload? And if this is important for OLM can you add openshift.io/run-level: "1" label like other important SLOs.

[ecordell]

Thanks @abhinavdahiya - just made #620 to address this.

What is the use of openshift-operators namespace and why is this in the release payload?

openshift-operators is the "target" namespace where OLM installs operators for the cluster (global operators that provide services in all namespace, at least). It's in the release payload so that OLM operators can be installed out of the box.

And if this is important for OLM can you add openshift.io/run-level: "1" label like other important SLOs.

Added in #620

OLM is running at pretty high priority order (30) in release payload and is blocking installation of other operators for quite some time.

Can you help me understand how this is possible? The PRs that added this namespace all went green on e2e-aws, and we even switched our olm-specific e2e tests to run in the openshift-operators namespace. How did all of that succeed if it was blocking the installer?

[abhinavdahiya]

Can you help me understand how this is possible? The PRs that added this namespace all went green on e2e-aws, and we even switched our olm-specific e2e tests to run in the openshift-operators namespace. How did all of that succeed if it was blocking the installer?

OLM is running at pretty high priority order (30) in release payload and is blocking installation of other operators for quite some time .

e2e-aws succeeds but the error is causing delays as CVO needs to wait for openshift-apiserver to be running before it can push objects to non openshift.io/run-level: "1" namespaces, hence delaying creation of operators in lower priority...

[ecordell]

Ah, I see - thanks. The fix should merge soon.

…

On Wed, Dec 12, 2018 at 8:05 PM Abhinav Dahiya ***@***.***> wrote: Can you help me understand how this is possible? The PRs that added this namespace all went green on e2e-aws, and we even switched our olm-specific e2e tests to run *in* the openshift-operators namespace. How did all of that succeed if it was blocking the installer? OLM is running at pretty high priority order (30) in release payload and is* blocking installation of other operators for quite some time*. e2e-aws succeeds but the error is causing delays as CVO needs to wait for openshift-apiserver to be running before it can push objects to non openshift.io/run-level: "1" namespaces, hence *delaying* creation of operators in lower priority... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#619 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADix9Yhhp18440IrNP5ZciJFf7tuhSCks5u4afigaJpZM4ZQjJl> .