blocked-edges/4.14.0: Drop updates from 4.13.17 and 18 #4301
Conversation
This file contains hidden or 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
openshift-ci
bot
added
the
approved
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.
wking
force-pushed
the
drop-pre-4.13.19-updates-to-4.14
branch
from
29e0ce7 to
f0dc7e8
Compare
petr-muller
approved these changes
Oct 26, 2023
Member
petr-muller
left a comment
petr-muller
left a comment
There was a problem hiding this comment.
LGTM and it seems that we have a consensus, I will just drop a hold here if Lala wants to veto this (but earlier Slack message implies he doesn't)
/hold
openshift-ci
bot
added
the
do-not-merge/hold
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: petr-muller, wking The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Member
|
/hold cancel |
openshift-ci
bot
removed
the
do-not-merge/hold
Member
Author
|
/retest-required |
This was referenced Oct 27, 2023
Contributor
|
@wking: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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 31, 2023
…from 4.13 Temporary hack to avoid declaring conditional updates from 4.13.17 and 4.13.18 to 4.14.0: $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?arch=multi&channel=fast-4.14' | jq '.conditionalEdges[] | .risks as $r | .edges[] | select(.from == "4.13.18" and .to == "4.14.0") | $r' [ { "url": "https://issues.redhat.com/browse/OTA-1031", "name": "ConsoleImplicitlyEnabled", "message": "Clusters with the Console capability disabled will have it implicitly enabled by updating to the target release, and once enabled, capabilities cannot be disabled.", "matchingRules": [ { "type": "PromQL", "promql": { "promql": "1 - max(cluster_version_capability{name=\"Console\"})\n" } } ] } ] when f0dc7e8 (blocked-edges/4.14.0: Drop updates from 4.13.17 and 18, 2023-10-26, openshift#4301) wanted those silently dropped. We'll likely need new Cincinnati code to handle this kind of overlap, in case we discover a risk that applies to 4.13.19 to 4.14.0, but for now, drop the overlapping conditional risk.
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Nov 1, 2023
The regression occured in 4.14.0-rc.2 [1], so updates like 4.14.0 to 4.14.1 are not exposed. The new regular expression covers: * Updates from 4.14.0-ec.*, since these predate the rc.2 regression. * Updates from 4.14.0-rc.[01], since these predate the rc.2 regression. * Updates from 4.13.*, since these predate the 4.14 regression. 4.14.0 is coming back, after 897f57f (blocked-edges/4.14.0-ConsoleImplicitlyEnabled: Drop conditional risk from 4.13, 2023-10-31, openshift#4326) had dropped it, with a special 'from' regular expression that replaces the 4.13.* with 4.13.19, to avoid having 4.13.17 -> 4.14.0 and 4.13.18 -> 4.14.0 sneak back in, as discussed in 4.14.0. The history of the updates from 4.13 to 4.14.0 is now: * f0dc7e8 (blocked-edges/4.14.0: Drop updates from 4.13.17 and 18, 2023-10-26, openshift#4301) dropped 4.13.17 and 18 from 4.14.0 update sources completely, and merged 2023-10-27, before 4.14.0 entered candidate-4.* channels. * 82ac96beb5 (blocked-edges/4.14.0*: Declare ConsoleImplicitlyEnabled, 2023-10-13, openshift#4234) landed 2023-10-30 via 6db078f, accidentally pulling updates from 4.13.17 and 18 back into channels because of how Cincinnati currently handles the overlap between: $ hack/show-edges.py --revision 6db078f candidate-4.14 | grep ' 4[.]14[.]0$' 4.13.17 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # my patched show-edges doesn't include this, but Cincinnati will until [2] is fixed 4.13.18 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # my patched show-edges doesn't include this, but Cincinnati will until [2] is fixed 4.14.0-ec.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 ... 4.14.0-rc.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.2 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # not actually exposed, but 'from' wildcard wasn't precise at this point ... 4.14.0-rc.7 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # not actually exposed, but 'from' wildcard wasn't precise at this point * c3fc9f0 (Merge pull request openshift#4318 from openshift-ota-bot/promote-4.13.19-to-candidate-4.14, 2023-10-30) lands, and 4.13.19 to 4.14.0 has ConsoleImplicitlyEnabled, as intended: $ hack/show-edges.py --revision c3fc9f0 candidate-4.14 | grep '^4[.]13[.]19 .* 4[.]14[.]0$' 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 But Cincinnati still has the: 4.13.17 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.13.18 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 that we don't want. * ba3396f (Merge pull request openshift#4326 from wking/4.14.0-drop-ConsoleImplicitlyEnabled, 2023-10-31) lands, removing the updates from 4.13.17 and 18 which 82ac96beb5 and [2] had added, but leaving ConsoleImplicitlyEnabled undeclared for 4.13.19 to 4.14.0: $ hack/show-edges.py --revision ba3396f candidate-4.14 | grep '^4[.]13[.].* .* 4[.]14[.]0$' 4.13.19 -> 4.14.0 # but this is exposed to ConsoleImplicitlyEnabled, although we no longer declare the risk * This commit restores the ConsoleImplicitlyEnabled risk for 4.14.0, and the fancy 'from' regular expressions get the whole thing the way we want it: $ hack/show-edges.py candidate-4.14 | grep ' 4[.]14[.]0$' 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # now declares ConsoleImplicitlyEnabled again, fixing ba3396f's issues 4.14.0-ec.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # continues to declare ConsoleImplicitlyEnabled 4.14.0-ec.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.2 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.3 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.4 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.2 -> 4.14.0 # this and later no longer claim ConsoleImplicitlyEnabled exposure, because both the source and target release are in the impacted set, and those updates do not increase exposure 4.14.0-rc.3 -> 4.14.0 4.14.0-rc.4 -> 4.14.0 4.14.0-rc.5 -> 4.14.0 4.14.0-rc.6 -> 4.14.0 4.14.0-rc.7 -> 4.14.0 [1]: https://issues.redhat.com/browse/OTA-1031 [2]: https://issues.redhat.com/browse/OTA-1043
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Nov 1, 2023
…sions The regression occured in 4.14.0-rc.2 [1], so updates like 4.14.0 to 4.14.1 are not exposed. The new regular expression covers: * Updates from 4.14.0-ec.*, since these predate the rc.2 regression. * Updates from 4.14.0-rc.[01], since these predate the rc.2 regression. * Updates from 4.13.*, since these predate the 4.14 regression. 4.14.0 is coming back, after 897f57f (blocked-edges/4.14.0-ConsoleImplicitlyEnabled: Drop conditional risk from 4.13, 2023-10-31, openshift#4326) had dropped it, with a special 'from' regular expression that replaces the 4.13.* with 4.13.19, to avoid having 4.13.17 -> 4.14.0 and 4.13.18 -> 4.14.0 sneak back in, as discussed in 897f57f. The history of the updates from 4.13 to 4.14.0 is now: * f0dc7e8 (blocked-edges/4.14.0: Drop updates from 4.13.17 and 18, 2023-10-26, openshift#4301) dropped 4.13.17 and 18 from 4.14.0 update sources completely, and merged 2023-10-27, before 4.14.0 entered candidate-4.* channels. * 82ac96beb5 (blocked-edges/4.14.0*: Declare ConsoleImplicitlyEnabled, 2023-10-13, openshift#4234) landed 2023-10-30 via 6db078f, accidentally pulling updates from 4.13.17 and 18 back into channels because of how Cincinnati currently handles the overlap between: $ hack/show-edges.py --revision 6db078f candidate-4.14 | grep ' 4[.]14[.]0$' 4.13.17 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # my patched show-edges doesn't include this, but Cincinnati will until [2] is fixed 4.13.18 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # my patched show-edges doesn't include this, but Cincinnati will until [2] is fixed 4.14.0-ec.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 ... 4.14.0-rc.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.2 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # not actually exposed, but 'from' wildcard wasn't precise at this point ... 4.14.0-rc.7 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # not actually exposed, but 'from' wildcard wasn't precise at this point * c3fc9f0 (Merge pull request openshift#4318 from openshift-ota-bot/promote-4.13.19-to-candidate-4.14, 2023-10-30) lands, and 4.13.19 to 4.14.0 has ConsoleImplicitlyEnabled, as intended: $ hack/show-edges.py --revision c3fc9f0 candidate-4.14 | grep '^4[.]13[.]19 .* 4[.]14[.]0$' 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 But Cincinnati still has the: 4.13.17 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.13.18 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 that we don't want. * ba3396f (Merge pull request openshift#4326 from wking/4.14.0-drop-ConsoleImplicitlyEnabled, 2023-10-31) lands, removing the updates from 4.13.17 and 18 which 82ac96beb5 and [2] had added, but leaving ConsoleImplicitlyEnabled undeclared for 4.13.19 to 4.14.0: $ hack/show-edges.py --revision ba3396f candidate-4.14 | grep '^4[.]13[.].* .* 4[.]14[.]0$' 4.13.19 -> 4.14.0 # but this is exposed to ConsoleImplicitlyEnabled, although we no longer declare the risk * This commit restores the ConsoleImplicitlyEnabled risk for 4.14.0, and the fancy 'from' regular expressions get the whole thing the way we want it: $ hack/show-edges.py candidate-4.14 | grep ' 4[.]14[.]0$' 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # now declares ConsoleImplicitlyEnabled again, fixing ba3396f's issues 4.14.0-ec.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # continues to declare ConsoleImplicitlyEnabled 4.14.0-ec.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.2 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.3 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.4 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.2 -> 4.14.0 # this and later no longer claim ConsoleImplicitlyEnabled exposure, because both the source and target release are in the impacted set, and those updates do not increase exposure 4.14.0-rc.3 -> 4.14.0 4.14.0-rc.4 -> 4.14.0 4.14.0-rc.5 -> 4.14.0 4.14.0-rc.6 -> 4.14.0 4.14.0-rc.7 -> 4.14.0 [1]: https://issues.redhat.com/browse/OTA-1031 [2]: https://issues.redhat.com/browse/OTA-1043
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Nov 1, 2023
…sions The regression occured in 4.14.0-rc.2 [1], so updates like 4.14.0 to 4.14.1 are not exposed. The new regular expression covers: * Updates from 4.14.0-ec.*, since these predate the rc.2 regression. * Updates from 4.14.0-rc.[01], since these predate the rc.2 regression. * Updates from 4.13.*, since these predate the 4.14 regression. 4.14.0 is coming back, after 897f57f (blocked-edges/4.14.0-ConsoleImplicitlyEnabled: Drop conditional risk from 4.13, 2023-10-31, openshift#4326) had dropped it, with a special 'from' regular expression that replaces the 4.13.* with 4.13.19, to avoid having 4.13.17 -> 4.14.0 and 4.13.18 -> 4.14.0 sneak back in, as discussed in 897f57f. The history of the updates from 4.13 to 4.14.0 is now: * f0dc7e8 (blocked-edges/4.14.0: Drop updates from 4.13.17 and 18, 2023-10-26, openshift#4301) dropped 4.13.17 and 18 from 4.14.0 update sources completely, and merged 2023-10-27, before 4.14.0 entered candidate-4.* channels. * 82ac96beb5 (blocked-edges/4.14.0*: Declare ConsoleImplicitlyEnabled, 2023-10-13, openshift#4234) landed 2023-10-30 via 6db078f, accidentally pulling updates from 4.13.17 and 18 back into channels because of how Cincinnati currently handles the overlap between: $ hack/show-edges.py --revision 6db078f candidate-4.14 | grep ' 4[.]14[.]0$' 4.13.17 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # my patched show-edges doesn't include this, but Cincinnati will until [2] is fixed 4.13.18 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # my patched show-edges doesn't include this, but Cincinnati will until [2] is fixed 4.14.0-ec.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 ... 4.14.0-rc.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.2 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # not actually exposed, but 'from' wildcard wasn't precise at this point ... 4.14.0-rc.7 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # not actually exposed, but 'from' wildcard wasn't precise at this point * c3fc9f0 (Merge pull request openshift#4318 from openshift-ota-bot/promote-4.13.19-to-candidate-4.14, 2023-10-30) lands, and 4.13.19 to 4.14.0 has ConsoleImplicitlyEnabled, as intended: $ hack/show-edges.py --revision c3fc9f0 candidate-4.14 | grep '^4[.]13[.]19 .* 4[.]14[.]0$' 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 But Cincinnati still has the: 4.13.17 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.13.18 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 that we don't want. * ba3396f (Merge pull request openshift#4326 from wking/4.14.0-drop-ConsoleImplicitlyEnabled, 2023-10-31) lands, removing the updates from 4.13.17 and 18 which 82ac96beb5 and [2] had added, but leaving ConsoleImplicitlyEnabled undeclared for 4.13.19 to 4.14.0: $ hack/show-edges.py --revision ba3396f candidate-4.14 | grep '^4[.]13[.].* .* 4[.]14[.]0$' 4.13.19 -> 4.14.0 # but this is exposed to ConsoleImplicitlyEnabled, although we no longer declare the risk * This commit restores the ConsoleImplicitlyEnabled risk for 4.14.0, and the fancy 'from' regular expressions get the whole thing the way we want it: $ hack/show-edges.py candidate-4.14 | grep ' 4[.]14[.]0$' 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # now declares ConsoleImplicitlyEnabled again, fixing ba3396f's issues 4.14.0-ec.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # continues to declare ConsoleImplicitlyEnabled 4.14.0-ec.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.2 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.3 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.4 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.2 -> 4.14.0 # this and later no longer claim ConsoleImplicitlyEnabled exposure, because both the source and target release are in the impacted set, and those updates do not increase exposure 4.14.0-rc.3 -> 4.14.0 4.14.0-rc.4 -> 4.14.0 4.14.0-rc.5 -> 4.14.0 4.14.0-rc.6 -> 4.14.0 4.14.0-rc.7 -> 4.14.0 [1]: https://issues.redhat.com/browse/OTA-1031 [2]: https://issues.redhat.com/browse/OTA-1043
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Nov 1, 2023
The regression occured in 4.14.0-rc.2 [1], so updates like 4.14.0 to 4.14.1 are not exposed. The new regular expression covers: * Updates from 4.14.0-ec.*, since these predate the rc.2 regression. * Updates from 4.14.0-rc.[01], since these predate the rc.2 regression. * Updates from 4.13.*, since these predate the 4.14 regression. 4.14.0 is coming back, after 897f57f (blocked-edges/4.14.0-ConsoleImplicitlyEnabled: Drop conditional risk from 4.13, 2023-10-31, openshift#4326) had dropped it, with a special 'from' regular expression that replaces the 4.13.* with 4.13.19, to avoid having 4.13.17 -> 4.14.0 and 4.13.18 -> 4.14.0 sneak back in, as discussed in 897f57f. The history of the updates from 4.13 to 4.14.0 is now: * f0dc7e8 (blocked-edges/4.14.0: Drop updates from 4.13.17 and 18, 2023-10-26, openshift#4301) dropped 4.13.17 and 18 from 4.14.0 update sources completely, and merged 2023-10-27, before 4.14.0 entered candidate-4.* channels. * 82ac96beb5 (blocked-edges/4.14.0*: Declare ConsoleImplicitlyEnabled, 2023-10-13, openshift#4234) landed 2023-10-30 via 6db078f, accidentally pulling updates from 4.13.17 and 18 back into channels because of how Cincinnati currently handles the overlap between: $ hack/show-edges.py --revision 6db078f candidate-4.14 | grep ' 4[.]14[.]0$' 4.13.17 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.13.18 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 ... 4.14.0-rc.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.2 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # not actually exposed, but 'from' wildcard wasn't precise at this point ... 4.14.0-rc.7 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # not actually exposed, but 'from' wildcard wasn't precise at this point * c3fc9f0 (Merge pull request openshift#4318 from openshift-ota-bot/promote-4.13.19-to-candidate-4.14, 2023-10-30) lands, and 4.13.19 to 4.14.0 has ConsoleImplicitlyEnabled, as intended: $ hack/show-edges.py --revision c3fc9f0 candidate-4.14 | grep '^4[.]13[.].* 4[.]14[.]0$' 4.13.17 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.13.18 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 But we still don't like 4.13.17 and 18 showing up there with only ConsoleImplicitlyEnabled declared. * ba3396f (Merge pull request openshift#4326 from wking/4.14.0-drop-ConsoleImplicitlyEnabled, 2023-10-31) lands, removing the updates from 4.13.17 and 18 which 82ac96beb5 and [2] had added, but leaving ConsoleImplicitlyEnabled undeclared for 4.13.19 to 4.14.0: $ hack/show-edges.py --revision ba3396f candidate-4.14 | grep '^4[.]13[.].* 4[.]14[.]0$' 4.13.17 -(SILENT-BLOCK)-> 4.14.0 4.13.18 -(SILENT-BLOCK)-> 4.14.0 4.13.19 -> 4.14.0 # but this is exposed to ConsoleImplicitlyEnabled, although we no longer declare the risk * This commit restores the ConsoleImplicitlyEnabled risk for 4.14.0, and the fancy 'from' regular expressions get the whole thing the way we want it: $ hack/show-edges.py candidate-4.14 | grep ' 4[.]14[.]0$' 4.13.17 -(SILENT-BLOCK)-> 4.14.0 4.13.18 -(SILENT-BLOCK)-> 4.14.0 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # now declares ConsoleImplicitlyEnabled again, fixing ba3396f's issues 4.14.0-ec.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # continues to declare ConsoleImplicitlyEnabled 4.14.0-ec.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.2 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.3 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.4 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.2 -> 4.14.0 # this and later no longer claim ConsoleImplicitlyEnabled exposure, because both the source and target release are in the impacted set, and those updates do not increase exposure 4.14.0-rc.3 -> 4.14.0 4.14.0-rc.4 -> 4.14.0 4.14.0-rc.5 -> 4.14.0 4.14.0-rc.6 -> 4.14.0 4.14.0-rc.7 -> 4.14.0 [1]: https://issues.redhat.com/browse/OTA-1031 [2]: https://issues.redhat.com/browse/OTA-1043
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Nov 1, 2023
The regression occured in 4.14.0-rc.2 [1], so updates like 4.14.0 to 4.14.1 are not exposed. The new regular expression covers: * Updates from 4.14.0-ec.*, since these predate the rc.2 regression. * Updates from 4.14.0-rc.[01], since these predate the rc.2 regression. * Updates from 4.13.*, since these predate the 4.14 regression. 4.14.0 is coming back, after 897f57f (blocked-edges/4.14.0-ConsoleImplicitlyEnabled: Drop conditional risk from 4.13, 2023-10-31, openshift#4326) had dropped it, with a special 'from' regular expression that replaces the 4.13.* with 4.13.19, to avoid having 4.13.17 -> 4.14.0 and 4.13.18 -> 4.14.0 sneak back in, as discussed in 897f57f. The history of the updates from 4.13 to 4.14.0 is now: * f0dc7e8 (blocked-edges/4.14.0: Drop updates from 4.13.17 and 18, 2023-10-26, openshift#4301) dropped 4.13.17 and 18 from 4.14.0 update sources completely, and merged 2023-10-27, before 4.14.0 entered candidate-4.* channels. * 82ac96beb5 (blocked-edges/4.14.0*: Declare ConsoleImplicitlyEnabled, 2023-10-13, openshift#4234) landed 2023-10-30 via 6db078f, accidentally pulling updates from 4.13.17 and 18 back into channels because of how Cincinnati currently handles the overlap between: $ hack/show-edges.py --revision 6db078f candidate-4.14 | grep ' 4[.]14[.]0$' 4.13.17 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.13.18 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 ... 4.14.0-rc.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.2 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # not actually exposed, but 'from' wildcard wasn't precise at this point ... 4.14.0-rc.7 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # not actually exposed, but 'from' wildcard wasn't precise at this point * c3fc9f0 (Merge pull request openshift#4318 from openshift-ota-bot/promote-4.13.19-to-candidate-4.14, 2023-10-30) lands, and 4.13.19 to 4.14.0 has ConsoleImplicitlyEnabled, as intended: $ hack/show-edges.py --revision c3fc9f0 candidate-4.14 | grep '^4[.]13[.].* 4[.]14[.]0$' 4.13.17 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.13.18 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 But we still don't like 4.13.17 and 18 showing up there with only ConsoleImplicitlyEnabled declared. * ba3396f (Merge pull request openshift#4326 from wking/4.14.0-drop-ConsoleImplicitlyEnabled, 2023-10-31) lands, removing the updates from 4.13.17 and 18 which 82ac96beb5 and [2] had added, but leaving ConsoleImplicitlyEnabled undeclared for 4.13.19 to 4.14.0: $ hack/show-edges.py --revision ba3396f candidate-4.14 | grep '^4[.]13[.].* 4[.]14[.]0$' 4.13.17 -(SILENT-BLOCK)-> 4.14.0 4.13.18 -(SILENT-BLOCK)-> 4.14.0 4.13.19 -> 4.14.0 # but this is exposed to ConsoleImplicitlyEnabled, although we no longer declare the risk * This commit restores the ConsoleImplicitlyEnabled risk for 4.14.0, and the fancy 'from' regular expressions get the whole thing the way we want it: $ hack/show-edges.py candidate-4.14 | grep ' 4[.]14[.]0$' 4.13.17 -(SILENT-BLOCK)-> 4.14.0 4.13.18 -(SILENT-BLOCK)-> 4.14.0 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # now declares ConsoleImplicitlyEnabled again, fixing ba3396f's issues 4.14.0-ec.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # continues to declare ConsoleImplicitlyEnabled 4.14.0-ec.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.2 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.3 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.4 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.2 -> 4.14.0 # this and later no longer claim ConsoleImplicitlyEnabled exposure, because both the source and target release are in the impacted set, and those updates do not increase exposure 4.14.0-rc.3 -> 4.14.0 4.14.0-rc.4 -> 4.14.0 4.14.0-rc.5 -> 4.14.0 4.14.0-rc.6 -> 4.14.0 4.14.0-rc.7 -> 4.14.0 [1]: https://issues.redhat.com/browse/OTA-1031 [2]: https://issues.redhat.com/browse/OTA-1043
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Nov 1, 2023
The regression occured in 4.14.0-rc.2 [1], so updates like 4.14.0 to 4.14.1 are not exposed. The new regular expression covers: * Updates from 4.14.0-ec.*, since these predate the rc.2 regression. * Updates from 4.14.0-rc.[01], since these predate the rc.2 regression. * Updates from 4.13.*, since these predate the 4.14 regression. 4.14.0 is coming back, after 897f57f (blocked-edges/4.14.0-ConsoleImplicitlyEnabled: Drop conditional risk from 4.13, 2023-10-31, openshift#4326) had dropped it, with a special 'from' regular expression that replaces the 4.13.* with 4.13.19, to avoid having 4.13.17 -> 4.14.0 and 4.13.18 -> 4.14.0 sneak back in, as discussed in 897f57f. The history of the updates from 4.13 to 4.14.0 is now: * f0dc7e8 (blocked-edges/4.14.0: Drop updates from 4.13.17 and 18, 2023-10-26, openshift#4301) dropped 4.13.17 and 18 from 4.14.0 update sources completely, and merged 2023-10-27, before 4.14.0 entered candidate-4.* channels. * 82ac96beb5 (blocked-edges/4.14.0*: Declare ConsoleImplicitlyEnabled, 2023-10-13, openshift#4234) landed 2023-10-30 via 6db078f, accidentally pulling updates from 4.13.17 and 18 back into channels because of how Cincinnati currently handles the overlap between: $ hack/show-edges.py --revision 6db078f candidate-4.14 | grep ' 4[.]14[.]0$' 4.13.17 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.13.18 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 ... 4.14.0-rc.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.2 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # not actually exposed, but 'from' wildcard wasn't precise at this point ... 4.14.0-rc.7 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # not actually exposed, but 'from' wildcard wasn't precise at this point * c3fc9f0 (Merge pull request openshift#4318 from openshift-ota-bot/promote-4.13.19-to-candidate-4.14, 2023-10-30) lands, and 4.13.19 to 4.14.0 has ConsoleImplicitlyEnabled, as intended: $ hack/show-edges.py --revision c3fc9f0 candidate-4.14 | grep '^4[.]13[.].* 4[.]14[.]0$' 4.13.17 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.13.18 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 But we still don't like 4.13.17 and 18 showing up there with only ConsoleImplicitlyEnabled declared. * ba3396f (Merge pull request openshift#4326 from wking/4.14.0-drop-ConsoleImplicitlyEnabled, 2023-10-31) lands, removing the updates from 4.13.17 and 18 which 82ac96beb5 and [2] had added, but leaving ConsoleImplicitlyEnabled undeclared for 4.13.19 to 4.14.0: $ hack/show-edges.py --revision ba3396f candidate-4.14 | grep '^4[.]13[.].* 4[.]14[.]0$' 4.13.17 -(SILENT-BLOCK)-> 4.14.0 4.13.18 -(SILENT-BLOCK)-> 4.14.0 4.13.19 -> 4.14.0 # but this is exposed to ConsoleImplicitlyEnabled, although we no longer declare the risk * This commit restores the ConsoleImplicitlyEnabled risk for 4.14.0, and the fancy 'from' regular expressions get the whole thing the way we want it: $ hack/show-edges.py candidate-4.14 | grep ' 4[.]14[.]0$' 4.13.17 -(SILENT-BLOCK)-> 4.14.0 4.13.18 -(SILENT-BLOCK)-> 4.14.0 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # now declares ConsoleImplicitlyEnabled again, fixing ba3396f's issues 4.14.0-ec.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # continues to declare ConsoleImplicitlyEnabled 4.14.0-ec.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.2 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.3 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.4 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.2 -> 4.14.0 # this and later no longer claim ConsoleImplicitlyEnabled exposure, because both the source and target release are in the impacted set, and those updates do not increase exposure 4.14.0-rc.3 -> 4.14.0 4.14.0-rc.4 -> 4.14.0 4.14.0-rc.5 -> 4.14.0 4.14.0-rc.6 -> 4.14.0 4.14.0-rc.7 -> 4.14.0 [1]: https://issues.redhat.com/browse/OTA-1031 [2]: https://issues.redhat.com/browse/OTA-1043
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Nov 1, 2023
The regression occured in 4.14.0-rc.2 [1], so updates like 4.14.0 to 4.14.1 are not exposed. The new regular expression covers: * Updates from 4.14.0-ec.*, since these predate the rc.2 regression. * Updates from 4.14.0-rc.[01], since these predate the rc.2 regression. * Updates from 4.13.*, since these predate the 4.14 regression. 4.14.0 is coming back, after 897f57f (blocked-edges/4.14.0-ConsoleImplicitlyEnabled: Drop conditional risk from 4.13, 2023-10-31, openshift#4326) had dropped it, with a special 'from' regular expression that replaces the 4.13.* with 4.13.19, to avoid having 4.13.17 -> 4.14.0 and 4.13.18 -> 4.14.0 sneak back in, as discussed in 897f57f. The history of the updates from 4.13 to 4.14.0 is now: * f0dc7e8 (blocked-edges/4.14.0: Drop updates from 4.13.17 and 18, 2023-10-26, openshift#4301) dropped 4.13.17 and 18 from 4.14.0 update sources completely, and merged 2023-10-27, before 4.14.0 entered candidate-4.* channels. * 82ac96beb5 (blocked-edges/4.14.0*: Declare ConsoleImplicitlyEnabled, 2023-10-13, openshift#4234) landed 2023-10-30 via 6db078f, accidentally pulling updates from 4.13.17 and 18 back into channels because of how Cincinnati currently handles the overlap between: $ hack/show-edges.py --revision 6db078f candidate-4.14 | grep ' 4[.]14[.]0$' 4.13.17 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.13.18 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 ... 4.14.0-rc.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.2 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # not actually exposed, but 'from' wildcard wasn't precise at this point ... 4.14.0-rc.7 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # not actually exposed, but 'from' wildcard wasn't precise at this point * c3fc9f0 (Merge pull request openshift#4318 from openshift-ota-bot/promote-4.13.19-to-candidate-4.14, 2023-10-30) lands, and 4.13.19 to 4.14.0 has ConsoleImplicitlyEnabled, as intended: $ hack/show-edges.py --revision c3fc9f0 candidate-4.14 | grep '^4[.]13[.].* 4[.]14[.]0$' 4.13.17 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.13.18 -(risks: SILENT-BLOCK-CINCINNATI-WILL-IGNORE, ConsoleImplicitlyEnabled)-> 4.14.0 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 But we still don't like 4.13.17 and 18 showing up there with only ConsoleImplicitlyEnabled declared. * ba3396f (Merge pull request openshift#4326 from wking/4.14.0-drop-ConsoleImplicitlyEnabled, 2023-10-31) lands, removing the updates from 4.13.17 and 18 which 82ac96beb5 and [2] had added, but leaving ConsoleImplicitlyEnabled undeclared for 4.13.19 to 4.14.0: $ hack/show-edges.py --revision ba3396f candidate-4.14 | grep '^4[.]13[.].* 4[.]14[.]0$' 4.13.17 -(SILENT-BLOCK)-> 4.14.0 4.13.18 -(SILENT-BLOCK)-> 4.14.0 4.13.19 -> 4.14.0 # but this is exposed to ConsoleImplicitlyEnabled, although we no longer declare the risk * This commit restores the ConsoleImplicitlyEnabled risk for 4.14.0, and the fancy 'from' regular expressions get the whole thing the way we want it: $ hack/show-edges.py candidate-4.14 | grep ' 4[.]14[.]0$' 4.13.17 -(SILENT-BLOCK)-> 4.14.0 4.13.18 -(SILENT-BLOCK)-> 4.14.0 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # now declares ConsoleImplicitlyEnabled again, fixing ba3396f's issues 4.14.0-ec.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # continues to declare ConsoleImplicitlyEnabled 4.14.0-ec.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.2 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.3 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-ec.4 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.0 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.1 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.14.0-rc.2 -> 4.14.0 # this and later no longer claim ConsoleImplicitlyEnabled exposure, because both the source and target release are in the impacted set, and those updates do not increase exposure 4.14.0-rc.3 -> 4.14.0 4.14.0-rc.4 -> 4.14.0 4.14.0-rc.5 -> 4.14.0 4.14.0-rc.6 -> 4.14.0 4.14.0-rc.7 -> 4.14.0 [1]: https://issues.redhat.com/browse/OTA-1031 [2]: https://issues.redhat.com/browse/OTA-1043
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Dec 20, 2023
Generated by writing the 4.14.1 risk by hand, and then running: $ (curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=candidate-4.14&arch=amd64' | jq -r '.nodes[] | .version' | grep '^4[.]14[.]' | grep -v '^4[.]14[.][01]$') | while read VERSION; do sed "s/4.14.1/${VERSION}/" blocked-edges/4.14.1-AzureDefaultVMType.yaml > "blocked-edges/${VERSION}-AzureDefaultVMType.yaml"; done I also manually added the silent-drop to 4.14.0. We have almost entirely avoided silent drops since growing the ability to declare conditional risks in 4.10. But f0dc7e8 (blocked-edges/4.14.0: Drop updates from 4.13.17 and 18, 2023-10-26, openshift#4301) decided to use silent drops for 4.13.17 and 4.13.18 to 4.14.0. As described in that commit message, there are trade-offs between silent-drops and an Always risk for those updates. With this commit, we double-down on the silent-drop approach. Because we're dropping 4.13.19 to 4.14.0 after it has been a supported update for so long, there is a larger risk (than there was for 4.13.17 and 4.13.18 updates) of customers noticing the drop and being confused about where the 4.13.19 to 4.14.0 update went. That's why we developed the conditional update system in the first place. That risk is mitigated by the fact that 4.14.0 is fairly old by now, with many subsequent 4.14.z that fix a number of other issues. So we do not expect there to be much residual interest in 4.13.19 to 4.14.0 updates. If it turns out that there is enough "where did 4.13.19 to 4.14.0 go?" support load to warrant a pivot, future work could move us to explicitly-declared risk for all of the issues from 4.13.z to 4.14.0, including the original "4.13.19 adds a guard you want first" that f0dc7e8 was delivering. But the price of that pivot is the: 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... trade-off discussed in f0dc7e8.
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Dec 20, 2023
Generated by writing the 4.14.1 risk by hand, and then running: $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=candidate-4.14&arch=amd64' | jq -r '.nodes[] | .version' | grep '^4[.]14[.]' | grep -v '^4[.]14[.][01]$' | while read VERSION; do sed "s/4.14.1/${VERSION}/" blocked-edges/4.14.1-AzureDefaultVMType.yaml > "blocked-edges/${VERSION}-AzureDefaultVMType.yaml"; done I also manually added the silent-drop to 4.14.0. We have almost entirely avoided silent drops since growing the ability to declare conditional risks in 4.10. But f0dc7e8 (blocked-edges/4.14.0: Drop updates from 4.13.17 and 18, 2023-10-26, openshift#4301) decided to use silent drops for 4.13.17 and 4.13.18 to 4.14.0. As described in that commit message, there are trade-offs between silent-drops and an Always risk for those updates. With this commit, we double-down on the silent-drop approach. Because we're dropping 4.13.19 to 4.14.0 after it has been a supported update for so long, there is a larger risk (than there was for 4.13.17 and 4.13.18 updates) of customers noticing the drop and being confused about where the 4.13.19 to 4.14.0 update went. That's why we developed the conditional update system in the first place. That risk is mitigated by the fact that 4.14.0 is fairly old by now, with many subsequent 4.14.z that fix a number of other issues. So we do not expect there to be much residual interest in 4.13.19 to 4.14.0 updates. If it turns out that there is enough "where did 4.13.19 to 4.14.0 go?" support load to warrant a pivot, future work could move us to explicitly-declared risk for all of the issues from 4.13.z to 4.14.0, including the original "4.13.19 adds a guard you want first" that f0dc7e8 was delivering. But the price of that pivot is the: 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... trade-off discussed in f0dc7e8.
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Dec 20, 2023
Generated by writing the 4.14.1 risk by hand, and then running: $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=candidate-4.14&arch=amd64' | jq -r '.nodes[] | .version' | grep '^4[.]14[.]' | grep -v '^4[.]14[.][01]$' | while read VERSION; do sed "s/4.14.1/${VERSION}/" blocked-edges/4.14.1-AzureDefaultVMType.yaml > "blocked-edges/${VERSION}-AzureDefaultVMType.yaml"; done I also manually added the silent-drop to 4.14.0. We have almost entirely avoided silent drops since growing the ability to declare conditional risks in 4.10. But f0dc7e8 (blocked-edges/4.14.0: Drop updates from 4.13.17 and 18, 2023-10-26, openshift#4301) decided to use silent drops for 4.13.17 and 4.13.18 to 4.14.0. As described in that commit message, there are trade-offs between silent-drops and an Always risk for those updates. With this commit, we double-down on the silent-drop approach. Because we're dropping 4.13.19 to 4.14.0 after it has been a supported update for so long, there is a larger risk (than there was for 4.13.17 and 4.13.18 updates) of customers noticing the drop and being confused about where the 4.13.19 to 4.14.0 update went. That's why we developed the conditional update system in the first place. That risk is mitigated by the fact that 4.14.0 is fairly old by now, with many subsequent 4.14.z that fix a number of other issues. So we do not expect there to be much residual interest in 4.13.19 to 4.14.0 updates. If it turns out that there is enough "where did 4.13.19 to 4.14.0 go?" support load to warrant a pivot, future work could move us to explicitly-declared risk for all of the issues from 4.13.z to 4.14.0, including the original "4.13.19 adds a guard you want first" that f0dc7e8 was delivering. But the price of that pivot is the: 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... trade-off discussed in f0dc7e8.
petr-muller
added a commit
to petr-muller/cincinnati-graph-data
that referenced
this pull request
May 9, 2024
Generated with https://github.com/petr-muller/ota/tree/main/cmd/graph-extend-or-fix by basically extending backwards: ```console for risk in AWSCustomDomainNodesNotReady AWSECRLegacyCredProvider AzureDefaultVMType AzureRegistryImagePreservation ConsoleImplicitlyEnabled IngressDegradedOnRouterReloads go run ./cmd/graph-extend-or-fix/... --jira-endpoint=https://issues.redhat.com --jira-bearer-token-file=$HOME/Temporary/jira-upgradeblocker-token --graph-repository-path=/home/pmuller/Projects/RH/github.com/openshift/cincinnati-graph-data --risk=$risk --last=4.14.1 --new=4.14.0 --do=extend end ``` I have not included the formatting changes in AWSCustomDomainNodesNotReady and IngressDegradedOnRouterReloads that already existed on 4.14.0 Initially we wanted to silently drop the 4.14.0 release from the graph but because of [OTA-1043](https://issues.redhat.com/browse/OTA-1043) it is hard to keep it that way, because we usually automate adding new 4.14 risks over individual patch updates and forget to avoid adding one for 4.14.0. This way we struggle to keep the drop in effect (see openshift#4339 and openshift#4301), so we decided to give up and just bury 4.14.0 in conditional risks.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
We'd raised the floor for 4.13-to-4.14 in 1db9474 (
#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
Alwaysrisk: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
Alwaysrisk 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
Alwaysrisk would reduce the chances that folks saw: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
Alwaysor 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.