Description of problem: In OpenShift 4.4, the default SCCs are managed by CVO. This means any changes to it are stomped by CVO. We have customers who change the default SCCs for their workload. when a cluster upgrades from 4.3 -> 4.4, user's changes to the default SCCs will be stomped by CVO and customer workload will face outages consequently. Version-Release number of selected component (if applicable): OpenShift 4.4 How reproducible: Always Steps to Reproduce: 1. Install OpenShift 4.3 2. Change the default SCC oc patch scc privileged --type json -p '[{"op": "add", "path": "/users/-", "value": "kubeadmin"}]' oc patch scc anyuid --type json -p '[{"op": "add", "path": "/users/-", "value": "kubeadmin"}]' 3. do a 4.3 -> 4.4 upgrade Actual results: Changes to the default SCCs will be lost as a result of the upgrade. Expected results: The upgrade should retain the changes made by the user Additional info: - https://bugzilla.redhat.com/show_bug.cgi?id=1823921
Waiting for the PR in master - https://github.com/openshift/cluster-kube-apiserver-operator/pull/831 to merge. Then it will be cherry-picked into 4.4.
once the back port to 4.4 https://github.com/openshift/cluster-kube-apiserver-operator/pull/836 merges I will revert it to ON_QA. I did not know of any other way to convince CI to allow my PR to merge.
My PR has merged, reverting it back to ON_QA.
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, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:2409