Bug 1730401

Summary: Feature gate setting for TechPreviewNoUpgrade is not respected by the CVO
Product: OpenShift Container Platform Reporter: Derek Carr <decarr>
Component: Cluster Version OperatorAssignee: Abhinav Dahiya <adahiya>
Status: CLOSED ERRATA QA Contact: Weinan Liu <weinliu>
Severity: high Docs Contact:
Priority: high    
Version: 4.2.0CC: adahiya, aos-bugs, ccoleman, eparis, jokerman, schoudha, sdodson, tnozicka, wking
Target Milestone: ---Keywords: Reopened
Target Release: 4.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1739504 (view as bug list) Environment:
Last Closed: 2020-01-23 11:04:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Derek Carr 2019-07-16 15:29:36 UTC
Description of problem:

The CVO should block an upgrade of a cluster whose FeatureGate is configured for TechPreviewNoUpgrade when upgrading across minor versions.

Actual results:
The cluster upgrade is not blocked.

Expected results:
The cluster upgrade should be blocked across minor versions.

Comment 1 Clayton Coleman 2019-07-30 13:34:53 UTC
This probably needs an API change (and a design) if we put it in the CVO, because we don't want the existing `force` flag to be used for this (that teaches users to run unsecured content).   We can have oc adm upgrade check Upgradeable and bypass if --bypass-tech-preview or similar.

Comment 2 W. Trevor King 2019-08-01 23:57:52 UTC
> The cluster upgrade should be blocked across minor versions.

Only minor versions?  The docs [1] say "PREVENTS UPGRADES", which sounds like "no upgrades at all" which would include patch-level changes or anything else that required looking at a different release image.  But maybe we're confident enough in patch-level changes that we don't feel the need to block them?  Personally I don't see a problem forcing users to delete/recreate their cluster after they've set this, even for minor bumps.

> We can have oc adm upgrade check Upgradeable and bypass if --bypass-tech-preview or similar.

Is this something we want to allow people to bypass?  The docs also say this setting "CANNOT BE UNDONE".

[1]: https://github.com/openshift/api/blob/0922aa5a655be314e20a3e0e94f4f2b105100154/config/v1/types_feature.go#L31

Comment 3 Abhinav Dahiya 2019-08-15 21:03:17 UTC
This is feature request for cluster version operator, So I think we should track it in JIRA rather bug.

Comment 4 Eric Paris 2019-08-20 15:06:47 UTC
I'm reopenning. This is a 4.2 release blocker. We screwed up in 4.1 and have a bug that upgrades were not blocked.

Comment 5 Eric Paris 2019-08-20 17:43:12 UTC
For 4.2 if techpreviewnoupgrade is set please just block all upgrades. --force should allow it to work.

In 4.3 we can make something more intelligent which requires design. We said tech preview would block upgrade but didn't implement it. So instead the apiserver team did implement it, but only in the apiserver. They did no intelligence. This was wrong. The bug was about changing the cluster version, and so the cluster version operator should enforce it.

Comment 7 Abhinav Dahiya 2019-08-26 16:12:47 UTC
*** Bug 1739504 has been marked as a duplicate of this bug. ***

Comment 8 Clayton Coleman 2019-08-28 19:58:45 UTC
I would prefer not to do this in 4.2.  Eric and I need to sync - we had a number of discussions over the last week where not blocking upgrades has not been a significant issue in the fleet (the small percentage of upgrades we might block is dwarfed by the large number of upgrades that fail because we don't code good.

Comment 9 Clayton Coleman 2019-08-28 20:22:38 UTC
Eric and I talked through all the various discussions over the last week - he mostly convinced me that doing something is better than nothing, although our overall goal is to minimize risk of getting a cluster stuck by accident and not encouraging unsafe behavior.

Comment 16 errata-xmlrpc 2020-01-23 11:04:15 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, 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:0062