4.14: Bump minor_min to 4.13.19 to pickup the SCC gate
#4295
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
/hold We want to only merge once 4.13.19 is actually validated and released. |
openshift-ci
bot
added
the
do-not-merge/hold
openshift-ci
bot
added
the
approved
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: LalatenduMohanty, petr-muller The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Feel free to remove the hold once we are sure about openshift/cluster-version-operator#969 is in 4.13.19 |
|
/hold cancel |
openshift-ci
bot
removed
the
do-not-merge/hold
|
@petr-muller: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Oct 26, 2023
We'd raised the floor for 4.13-to-4.19 in 1db9474 (4.14: Bump `minor_min` to 4.13.19 to pickup the SCC gate, 2023-10-25, openshift#4295), but that only applies to automatically generated new releases. ART created the 4.14.0 metadata by hand, and included 4.13.17 and 4.13.18. But we do not recommend folks update from those to 4.14 without passing through 4.13.19 or later to get the SCC Upgradeable checker. There are some trade offs between this commit's silent drop vs. declaring an Always risk: * A silent drop simplifies update graphs, not even presenting the not-recommended updates which could distract customers that don't care about those updates. * A silent drop may mean we do not need to support customers who update from 4.13.17 or 18 directly to 4.14.0 and have some mutated SCCs stomped. Or at least, there are not explicit docs one way or the other about whether customers who do this will be supported. And with the updates silently dropped, the number of customers who do this update is expected to be very low. * An Always risk might have more customers thing "I probably didn't mutate my SCCs", accept the risk, and then be surprised when they actually had mutated their SCCs and the SCCs got stomped. * An Always risk would reduce the chances that folks saw: $ oc adm release info -o json quay.io/openshift-release-dev/ocp-release:4.14.0-x86_64 | jq -r '.metadata.previous[]' | grep '^4[.]13[.]' 4.13.17 4.13.18 4.13.19 and then opened support cases about why they didn't see 4.14.0 as a direct-hop update target in their 4.13.17 or 18 cluster (the transparency issues that conditional update risks was designed to address). Whether Always or silent-drops are better for customers is unclear. But soon 4.14.1 will come out, and after that, folks caring about updates to 4.14.0 will likely be very rare, so it doesn't seem like it's worth pinning down a technological winner, and we're going with silent-drop.
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Oct 26, 2023
We'd raised the floor for 4.13-to-4.14 in 1db9474 (4.14: Bump `minor_min` to 4.13.19 to pickup the SCC gate, 2023-10-25, openshift#4295), but that only applies to automatically generated new releases. ART created the 4.14.0 metadata by hand, and included 4.13.17 and 4.13.18. But we do not recommend folks update from those to 4.14 without passing through 4.13.19 or later to get the SCC Upgradeable checker. There are some trade offs between this commit's silent drop vs. declaring an Always risk: * A silent drop simplifies update graphs, not even presenting the not-recommended updates which could distract customers that don't care about those updates. * A silent drop may mean we do not need to support customers who update from 4.13.17 or 18 directly to 4.14.0 and have some mutated SCCs stomped. Or at least, there are not explicit docs one way or the other about whether customers who do this will be supported. And with the updates silently dropped, the number of customers who do this update is expected to be very low. * An Always risk might have more customers thing "I probably didn't mutate my SCCs", accept the risk, and then be surprised when they actually had mutated their SCCs and the SCCs got stomped. * An Always risk would reduce the chances that folks saw: $ oc adm release info -o json quay.io/openshift-release-dev/ocp-release:4.14.0-x86_64 | jq -r '.metadata.previous[]' | grep '^4[.]13[.]' 4.13.17 4.13.18 4.13.19 and then opened support cases about why they didn't see 4.14.0 as a direct-hop update target in their 4.13.17 or 18 cluster (the transparency issues that conditional update risks was designed to address). Whether Always or silent-drops are better for customers is unclear. But soon 4.14.1 will come out, and after that, folks caring about updates to 4.14.0 will likely be very rare, so it doesn't seem like it's worth pinning down a technological winner, and we're going with silent-drop.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Yet-nonexistent 4.13.19 is likely to be the 4.13 patch release picking up openshift/cluster-version-operator#969 which adds the
Upgradeable=Falsegate when modified SCC resources are detected in the cluster. We will want everyone to go through the CVO with this change, to prevent workloads from breaking if they depend on modified system SCC resources.