Bug 2111979 - openshift-controller-manager-operator NS runlevel needs to be set to emptystring
Summary: openshift-controller-manager-operator NS runlevel needs to be set to emptystring
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: openshift-controller-manager
Version: 4.12
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.12.0
Assignee: jawed
QA Contact: Jitendar Singh
Depends On:
TreeView+ depends on / blocked
Reported: 2022-07-28 14:38 UTC by Ben Parees
Modified: 2023-09-18 04:43 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2023-01-17 19:53:39 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift cluster-openshift-controller-manager-operator pull 269 0 None open Bug 2111979: Set openshift.io/run-level to nil in openshift-controller-manager nam… 2022-11-04 15:20:15 UTC
Red Hat Product Errata RHSA-2022:7399 0 None None None 2023-01-17 19:54:27 UTC

Description Ben Parees 2022-07-28 14:38:52 UTC
Description of problem:
openshift-controller-manager-operator NS runlevel needs to be set to empty string.

For the full history of this issue, see:

Currently the NS label is not set at all:

but historically it was set to "0":

Because the CVO doesn't remove deleted labels, this means clusters that started at an older version like 4.3.18 will still have this label present on the NS, which results in different SCC admission behavior.

To ensure we are consistent in our configurations, the NS label should instead be explicitly set to "", this way the CVO will apply the setting and overwrite the runlevel 0 setting.  See https://github.com/openshift/machine-api-operator/pull/1031/files#diff-9dfafd72c269693396fc68a6b83e130c3606cb7fb2d0f7bc17c3f9c7ac159d7fR13 for an example.

To verify the fix, we need to start from a 4.3.18 cluster and upgrade it to 4.12 successfully.  If the 4.12 upgrade is successful (openshift controller manager+operator don't fail due to SCC admission or CRIO container start issues), then the fix can be considered verified.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install a cluster from version 4.3.18
2. Upgrade the cluster all the way to 4.12
3a. Prior to this change, the cluster will successfully upgrade but the NS will still be labeled as openshift.io/run-level: "0" 
3b. After this change, the cluster will successfully upgrade but the NS will be labeled as openshift.io/run-level: ""

Actual results:
openshift-controller-manager-operator NS runlevel label is set to 0

Expected results:
runlevel label is set to emptystring

Comment 2 jawed 2022-11-04 07:00:26 UTC
@cdaley this was fixed here https://github.com/openshift/cluster-openshift-controller-manager-operator/pull/248

the PR is not actually referecing the right BZ, it is referencing https://bugzilla.redhat.com/show_bug.cgi?id=2110629
Initially it was about removing the runlevel label but the right fix was to set it to nil which the PR is actually doing

I will close the current one as duplicate of 2110629 if you dont mind

Comment 3 jawed 2022-11-04 07:02:06 UTC

*** This bug has been marked as a duplicate of bug 2110629 ***

Comment 4 Ben Parees 2022-11-04 14:09:15 UTC
Please read the bug description again.  There are two different NSes in question here, the other bug fixed a different NS.

You still need to fix this one:

because once upon a time it set this:

which means any clusters that installed that older version and have since upgraded, will still have that label set.

Comment 5 jawed 2022-11-04 15:21:07 UTC
thank you @bparees for spotting this
fixing this

Comment 10 errata-xmlrpc 2023-01-17 19:53:39 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.12.0 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Comment 11 Red Hat Bugzilla 2023-09-18 04:43:14 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days

Note You need to log in before you can comment on or make changes to this bug.