Skip to content

OTA-1031: blocked-edges/4.14.0*: Declare ConsoleImplicitlyEnabled #4234

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
openshift-ci merged 1 commit into from
Oct 30, 2023
Merged

OTA-1031: blocked-edges/4.14.0*: Declare ConsoleImplicitlyEnabled #4234

openshift-ci merged 1 commit into from
Oct 30, 2023

Conversation

@wking
Copy link
Member

@wking wking commented Oct 13, 2023

Generated by writing the rc.2 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[.]0-rc[.][3-9]' | while read VERSION; do sed "s/4.14.0-rc.2/${VERSION}/" blocked-edges/4.14.0-rc.2-ConsoleImplicitlyEnabled.yaml > "blocked-edges/${VERSION}-ConsoleImplicitlyEnabled.yaml"; done

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Oct 13, 2023
@openshift-ci-robot
Copy link

openshift-ci-robot commented Oct 13, 2023 •
edited by openshift-ci bot
Loading

@wking: This pull request references OTA-1031 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.15.0" version, but no target version was set.

Details

In response to this:

Generated by writing the rc.2 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[.]0-rc[.][3-9]' | while read VERSION; do sed "s/4.14.0-rc.2/${VERSION}/" blocked-edges/4.14.0-rc.2-ConsoleImplicitlyEnabled.yaml > "blocked-edges/${VERSION}-ConsoleImplicitlyEnabled.yaml"; done

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.

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 13, 2023
@wking wking force-pushed the ConsoleImplicitlyEnabled branch 2 times, most recently from b60b246 to cc1ad5c Compare October 14, 2023 21:28
@LalatenduMohanty
Copy link
Member

LalatenduMohanty commented Oct 16, 2023

/hold As I do not think this is an upgrade blocker. I agree that this is a regression but I do not agree that this is something we need to add conditional risk . When the webconsole is enabled , it is not causing any issues with existing workload or the availability of the cluster.

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 16, 2023
@wking wking force-pushed the ConsoleImplicitlyEnabled branch from cc1ad5c to e164727 Compare October 30, 2023 16:30
@wking wking changed the title OTA-1031: blocked-edges/4.14.0-rc.*: Declare ConsoleImplicitlyEnabled OTA-1031: blocked-edges/4.14.0*: Declare ConsoleImplicitlyEnabled Oct 30, 2023
@wking
blocked-edges/4.14.0*: Declare ConsoleImplicitlyEnabled
082ac96 
Generated by writing the rc.2 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[.]0\(-rc[.][3-9]\)\?$'; echo 4.14.1) | while read VERSION; do sed "s/4.14.0-rc.2/${VERSION}/" blocked-edges/4.14.0-rc.2-ConsoleImplicitlyEnabled.yaml > "blocked-edges/${VERSION}-ConsoleImplicitlyEnabled.yaml"; done

with the manual 4.14.1 injection because 4.14.1 is still exposed, but
we don't have the candidate-4.14 follow-up to 44d1044 (Enable
4.14.1 in candidate channel, 2023-10-27, openshift#4321) yet.
@wking wking force-pushed the ConsoleImplicitlyEnabled branch from e164727 to 082ac96 Compare October 30, 2023 16:31
@wking
Copy link
Member Author

wking commented Oct 30, 2023

Rebased to extend through 4.14.1 with cc1ad5c -> 082ac96.

@sdodson
Copy link
Member

sdodson commented Oct 30, 2023

/lgtm
/hold cancel
Since this triggers an irreversible action of enabling the console capability when it was undesired we should inform people of this risk before upgrading to 4.14.

@openshift-ci openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 30, 2023
@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Oct 30, 2023
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Oct 30, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sdodson, wking

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot merged commit 6db078f into openshift:master Oct 30, 2023
@wking wking deleted the ConsoleImplicitlyEnabled branch October 30, 2023 18:13
wking added a commit to wking/cincinnati-graph-data that referenced this pull request Nov 1, 2023
@wking
blocked-edges/4.14.*-ConsoleImplicitlyEnabled: Tune from versions
951a24b 
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
@wking
\0;276;0cblocked-edges/4.14.*-ConsoleImplicitlyEnabled: Tune from ver…
fef94f8 
…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
@wking
\0;276;0cblocked-edges/4.14.*-ConsoleImplicitlyEnabled: Tune from ver…
5f5deb4 
…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 wking mentioned this pull request Nov 1, 2023
Merged
wking added a commit to wking/cincinnati-graph-data that referenced this pull request Nov 1, 2023
@wking
blocked-edges/4.14.*-ConsoleImplicitlyEnabled: Tune from versions
f0902e1 
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
@wking
blocked-edges/4.14.*-ConsoleImplicitlyEnabled: Tune from versions
57e8eb7 
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
@wking
blocked-edges/4.14.*-ConsoleImplicitlyEnabled: Tune from versions
f3489ab 
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
@wking
blocked-edges/4.14.*-ConsoleImplicitlyEnabled: Tune from versions
361e132 
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@LalatenduMohanty LalatenduMohanty Awaiting requested review from LalatenduMohanty

@PratikMahajan PratikMahajan Awaiting requested review from PratikMahajan

Assignees

@sdodson sdodson

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@wking @openshift-ci-robot @LalatenduMohanty @sdodson