Bug 1829585

Summary:	Add e2e test for stale condition DefaultSecurityContextConstraints_Mutated
Product:	OpenShift Container Platform	Reporter:	Abu Kashem <akashem>
Component:	kube-apiserver	Assignee:	Abu Kashem <akashem>
Status:	CLOSED ERRATA	QA Contact:	Xingxing Xia <xxia>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	4.5	CC:	aos-bugs, bparees, mfojtik, xxia
Target Milestone:	---
Target Release:	4.5.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1829580	Environment:
Last Closed:	2020-04-29 20:14:16 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1829580

Description Abu Kashem 2020-04-29 20:12:22 UTC

+++ This bug was initially created as a clone of Bug #1829580 +++

+++ This bug was initially created as a clone of Bug #1829576 +++

Add an e2e test to validates that stale condition DefaultSecurityContextConstraintsUpgradeable is removed from the status block.

To make the release cut off, we validated manually and had to merge the corresponding PR without an e2e test.
PR: https://github.com/openshift/cluster-kube-apiserver-operator/pull/839
BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1827336

Comment 1 Abu Kashem 2020-04-29 20:14:16 UTC

This does not apply to 4.5, so closing it.

Comment 2 Ben Parees 2020-06-18 20:04:37 UTC

Abu can you elaborate on why this doesn't apply to 4.5 so i can confidently approve https://github.com/openshift/cluster-kube-apiserver-operator/pull/845 knowing that it doesn't need to be merged to 4.5 first?

Comment 3 Abu Kashem 2020-06-19 02:56:28 UTC

Hi bparees,
We added "DefaultSecurityContextConstraintsUpgradeable" (if a user mutates any default SCC then "Upgradeable" is set to "False") in 4.3. Then we realized that it is going to break a lot of customers.
So we decided to revert it, and remove the stale condition in 4.3.z stream. we back ported the revert in a rush to make the release cutoff window and did not have time to add the test at that time.
We also back ported "remove stale condition" in 4.4.z stream. This takes care of the situation if an affected 4.3 cluster has already upgraded to 4.4 with the stale condition (using --force)

It is impossible for the stale condition to make it to a 4.5 because only 4.3 cluster(s) were originally affected and the stale condition could make it to a 4.4 cluster via upgrade. once the cluster is upgraded to 4.4 the stale condition would get removed immediately. So a 4.5 cluster would never see the stale condition.

Comment 4 Ben Parees 2020-06-19 04:25:41 UTC

Thank you!