blocked-edges/4.14.0-ConsoleImplicitlyEnabled: Drop conditional risk from 4.13 #4326
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
…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.
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 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 |
openshift-ci
bot
added
the
approved
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. |
Member
Author
|
Reverts are cheap, and I don't like the narrow, |
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
Nov 1, 2023
…from 4.13 again Repeating 897f57f (blocked-edges/4.14.0-ConsoleImplicitlyEnabled: Drop conditional risk from 4.13, 2023-10-31, openshift#4326). I'd thought the tuned 'from' regular expressions in 361e132 (blocked-edges/4.14.*-ConsoleImplicitlyEnabled: Tune from versions, 2023-11-01, openshift#4337) would avoid the issue, but apparently not: $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?arch=amd64&channel=fast-4.14' | jq -r '.nodes[] | select(.version == "4.14.0").metadata["io.openshift.upgrades.graph.previous.remove_regex"]' 4[.](13[.]19|14[.]0-(ec[.].*|rc[.][01])) showing Cincinnati using the 'from' from the ConsoleImplicitlyEnabled, and apparently forgetting about the silent-drop from 4.14.0.yaml: $ hack/show-edges.py --cincinnati https://api.openshift.com/api/upgrades_info/graph --root-version 4.13.17 fast-4.14 4.13.17 -> 4.13.18 4.13.17 -> 4.13.19 4.13.17 -> 4.14.0 4.13.18 -> 4.13.19 4.13.18 -> 4.14.0 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.1 4.14.0 -> 4.14.1 This commit is expected to transition us to: $ hack/show-edges.py --root-version 4.13.17 fast-4.14 4.13.17 -> 4.13.18 4.13.17 -> 4.13.19 4.13.17 -(SILENT-BLOCK)-> 4.14.0 # better than the current unqualified recommendation 4.13.18 -> 4.13.19 4.13.18 -(SILENT-BLOCK)-> 4.14.0 # better than the current unqualified recommendation 4.13.19 -> 4.14.0 # we'd like this to mention ConsoleImplicitlyEnabled, but I'm back to not knowing how to get that to happen 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.1 4.14.0 -> 4.14.1
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Nov 1, 2023
…from 4.13 again Repeating 897f57f (blocked-edges/4.14.0-ConsoleImplicitlyEnabled: Drop conditional risk from 4.13, 2023-10-31, openshift#4326). I'd thought the tuned 'from' regular expressions in 361e132 (blocked-edges/4.14.*-ConsoleImplicitlyEnabled: Tune from versions, 2023-11-01, openshift#4337) would avoid the issue, but apparently not: $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?arch=amd64&channel=fast-4.14' | jq -r '.nodes[] | select(.version == "4.14.0").metadata["io.openshift.upgrades.graph.previous.remove_regex"]' 4[.](13[.]19|14[.]0-(ec[.].*|rc[.][01])) showing Cincinnati using the 'from' from the ConsoleImplicitlyEnabled, and apparently forgetting about the silent-drop from 4.14.0.yaml: $ hack/show-edges.py --cincinnati https://api.openshift.com/api/upgrades_info/graph --root-version 4.13.17 fast-4.14 4.13.17 -> 4.13.18 4.13.17 -> 4.13.19 4.13.17 -> 4.14.0 # this unqualified recommendation misses the mutated-SCC guard from 4.14.0.yaml 4.13.18 -> 4.13.19 4.13.18 -> 4.14.0 # this unqualified recommendation misses the mutated-SCC guard from 4.14.0.yaml 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.0 # we'd like to keep this 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.1 4.14.0 -> 4.14.1 This commit is expected to transition us to: $ hack/show-edges.py --root-version 4.13.17 fast-4.14 4.13.17 -> 4.13.18 4.13.17 -> 4.13.19 4.13.17 -(SILENT-BLOCK)-> 4.14.0 # better than the current unqualified recommendation 4.13.18 -> 4.13.19 4.13.18 -(SILENT-BLOCK)-> 4.14.0 # better than the current unqualified recommendation 4.13.19 -> 4.14.0 # we'd like this to mention ConsoleImplicitlyEnabled, but I'm back to not knowing how to get that to happen 4.13.19 -(risks: ConsoleImplicitlyEnabled)-> 4.14.1 4.14.0 -> 4.14.1
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Temporary hack to avoid declaring conditional updates from 4.13.17 and 4.13.18 to 4.14.0:
when f0dc7e8 (#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.