Bug 1730401 - Feature gate setting for TechPreviewNoUpgrade is not respected by the CVO
Summary: Feature gate setting for TechPreviewNoUpgrade is not respected by the CVO
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Cluster Version Operator
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.3.0
Assignee: Abhinav Dahiya
QA Contact: Weinan Liu
URL:
Whiteboard:
: 1739504 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-16 15:29 UTC by Derek Carr
Modified: 2020-01-23 11:04 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1739504 (view as bug list)
Environment:
Last Closed: 2020-01-23 11:04:15 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift cluster-version-operator pull 243 'None' closed Bug 1730401: prevent automatic upgrades for clusters with cluster operators reporting Upgradeable false 2020-02-05 18:25:59 UTC
Red Hat Product Errata RHBA-2020:0062 None None None 2020-01-23 11:04:40 UTC

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


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