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.
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.
> 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
This is feature request for cluster version operator, So I think we should track it in JIRA rather bug.
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.
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.
*** Bug 1739504 has been marked as a duplicate of this bug. ***
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.
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.
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