OCPBUGS-24535: pkg/payload/precondition/clusterversion/rollback: Allow previous version within z-stream #996
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@wking: This pull request references OTA-488 which is a valid jira issue. In response to this:
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
bot
added
the
approved
wking
force-pushed
the
allow-rollbacks-to-most-recently-previous-version
branch
from
309d16a
to
633c853
Compare
…ion within z-stream From [1], Lala, Scott, and Subin all agreed that rollbacks to the cluster's previous release should not be blocked, as long as the previous and current version had the same major.minor version (i.e. "within a z-stream", using x.y.z naming for major.minor.patch). We agreed to ignore whether the previous history entry is Completed or Partial, expecting that most users who are interested in rolling back will make that decision at the first sign of trouble, and not after attempting a few roll-forward retargets. [1]: https://issues.redhat.com/browse/OTA-553
wking
force-pushed
the
allow-rollbacks-to-most-recently-previous-version
branch
from
633c853
to
12fdd04
Compare
|
[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
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/test unit |
|
cc |
wking
changed the title
|
@wking: This pull request references Jira Issue OCPBUGS-24535, which is valid. 3 validation(s) were run on this bug
Requesting review from QA contact: The bug has been updated to refer to the pull request using the external bug tracker. In response to this:
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-robot
added
the
jira/valid-bug
|
/jira refresh The requirements for Jira bugs have changed (Jira issues linked to PRs on main branch need to target different OCP), recalculating validity. |
|
/label no_qe As it would be easier to test this post merge |
|
/label no-qe |
|
@LalatenduMohanty: The label(s) In response to this:
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. |
|
/label no-qe |
|
@JianLi-RH: The label(s) In response to this:
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. |
|
Trying again now that openshift/release#46849 has merged and updated the ConfigMap: /label no-qe |
|
/override ci/prow/e2e-agnostic-ovn |
|
@wking: Overrode contexts on behalf of wking: ci/prow/e2e-agnostic-ovn In response to this:
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. |
|
/override ci/prow/e2e-agnostic-ovn-upgrade-into-change |
|
@wking: Overrode contexts on behalf of wking: ci/prow/e2e-agnostic-ovn-upgrade-into-change In response to this:
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. |
|
@wking: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
@wking: Jira Issue OCPBUGS-24535: All pull requests linked via external trackers have merged: Jira Issue OCPBUGS-24535 has been moved to the MODIFIED state. In response to this:
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. |
|
[ART PR BUILD NOTIFIER] This PR has been included in build cluster-version-operator-container-v4.16.0-202312190511.p0.gbaef28d.assembly.stream for distgit cluster-version-operator. |
|
/cherrypick release-4.15 |
|
@wking: new pull request created: #1008 In response to this:
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. |
The "which release to roll back to?" criteria are matched to openshift/cluster-version-operator@12fdd0456b (pkg/payload/precondition/clusterversion/rollback: Allow previous version within z-stream, 2023-11-16, openshift/cluster-version-operator#996), where, based on [1], Lala, Scott, and Subin all agreed that rollbacks to the cluster's previous release should not be blocked, as long as the previous and current version had the same major.minor version (i.e. "within a z-stream", using x.y.z naming for major.minor.patch). We agreed to ignore whether the previous history entry is Completed or Partial, expecting that most users who are interested in rolling back will make that decision at the first sign of trouble, and not after attempting a few roll-forward retargets. I'm currently blocking Progressing!=False from rolling back, to align with our CI coverage in openshift/release@f4d37e7f87 (ci-operator/config/openshift/release: Use abort-at=100 for rollback-oldest-supported, 2023-10-31, openshift/release#45115). We could lift this restriction if we wanted to allow rollbacks to be requested from the middle of an in-progress update, but if we do, we'd probably want to add matching CI to cover that use-case. The new subcommand is hidden, as Lala requested in [2]'s Description on 2021-09-22. I have not put it behind a feature-gate environment variable in this commit, but that's also an option if we wanted to make it even less reachable. [1]: https://issues.redhat.com/browse/OTA-553 [2]: https://issues.redhat.com/browse/OTA-492
The "which release to roll back to?" criteria are matched to openshift/cluster-version-operator@12fdd0456b (pkg/payload/precondition/clusterversion/rollback: Allow previous version within z-stream, 2023-11-16, openshift/cluster-version-operator#996), where, based on [1], Lala, Scott, and Subin all agreed that rollbacks to the cluster's previous release should not be blocked, as long as the previous and current version had the same major.minor version (i.e. "within a z-stream", using x.y.z naming for major.minor.patch). We agreed to ignore whether the previous history entry is Completed or Partial, expecting that most users who are interested in rolling back will make that decision at the first sign of trouble, and not after attempting a few roll-forward retargets. I'm currently blocking Progressing!=False from rolling back, to align with our CI coverage in openshift/release@f4d37e7f87 (ci-operator/config/openshift/release: Use abort-at=100 for rollback-oldest-supported, 2023-10-31, openshift/release#45115). We could lift this restriction if we wanted to allow rollbacks to be requested from the middle of an in-progress update, but if we do, we'd probably want to add matching CI to cover that use-case. The new subcommand is hidden, as Lala requested in [2]'s Description on 2021-09-22. I have not put it behind a feature-gate environment variable in this commit, but that's also an option if we wanted to make it even less reachable. [1]: https://issues.redhat.com/browse/OTA-553 [2]: https://issues.redhat.com/browse/OTA-492
The "which release to roll back to?" criteria are matched to openshift/cluster-version-operator@12fdd0456b (pkg/payload/precondition/clusterversion/rollback: Allow previous version within z-stream, 2023-11-16, openshift/cluster-version-operator#996), where, based on [1], Lala, Scott, and Subin all agreed that rollbacks to the cluster's previous release should not be blocked, as long as the previous and current version had the same major.minor version (i.e. "within a z-stream", using x.y.z naming for major.minor.patch). We agreed to ignore whether the previous history entry is Completed or Partial, expecting that most users who are interested in rolling back will make that decision at the first sign of trouble, and not after attempting a few roll-forward retargets. I'm currently blocking Progressing!=False from rolling back, to align with our CI coverage in openshift/release@f4d37e7f87 (ci-operator/config/openshift/release: Use abort-at=100 for rollback-oldest-supported, 2023-10-31, openshift/release#45115). We could lift this restriction if we wanted to allow rollbacks to be requested from the middle of an in-progress update, but if we do, we'd probably want to add matching CI to cover that use-case. The new subcommand is hidden, as Lala requested in [2]'s Description on 2021-09-22. I have not put it behind a feature-gate environment variable in this commit, but that's also an option if we wanted to make it even less reachable. [1]: https://issues.redhat.com/browse/OTA-553 [2]: https://issues.redhat.com/browse/OTA-492
The "which release to roll back to?" criteria are matched to openshift/cluster-version-operator@12fdd0456b (pkg/payload/precondition/clusterversion/rollback: Allow previous version within z-stream, 2023-11-16, openshift/cluster-version-operator#996), where, based on [1], Lala, Scott, and Subin all agreed that rollbacks to the cluster's previous release should not be blocked, as long as the previous and current version had the same major.minor version (i.e. "within a z-stream", using x.y.z naming for major.minor.patch). We agreed to ignore whether the previous history entry is Completed or Partial, expecting that most users who are interested in rolling back will make that decision at the first sign of trouble, and not after attempting a few roll-forward retargets. I'm currently blocking Progressing!=False from rolling back, to align with our CI coverage in openshift/release@f4d37e7f87 (ci-operator/config/openshift/release: Use abort-at=100 for rollback-oldest-supported, 2023-10-31, openshift/release#45115). We could lift this restriction if we wanted to allow rollbacks to be requested from the middle of an in-progress update, but if we do, we'd probably want to add matching CI to cover that use-case. The new subcommand is hidden, as Lala requested in [2]'s Description on 2021-09-22. I have not put it behind a feature-gate environment variable in this commit, but that's also an option if we wanted to make it even less reachable. [1]: https://issues.redhat.com/browse/OTA-553 [2]: https://issues.redhat.com/browse/OTA-492
The "which release to roll back to?" criteria are matched to openshift/cluster-version-operator@12fdd0456b (pkg/payload/precondition/clusterversion/rollback: Allow previous version within z-stream, 2023-11-16, openshift/cluster-version-operator#996), where, based on [1], Lala, Scott, and Subin all agreed that rollbacks to the cluster's previous release should not be blocked, as long as the previous and current version had the same major.minor version (i.e. "within a z-stream", using x.y.z naming for major.minor.patch). We agreed to ignore whether the previous history entry is Completed or Partial, expecting that most users who are interested in rolling back will make that decision at the first sign of trouble, and not after attempting a few roll-forward retargets. I'm currently blocking Progressing!=False from rolling back, to align with our CI coverage in openshift/release@f4d37e7f87 (ci-operator/config/openshift/release: Use abort-at=100 for rollback-oldest-supported, 2023-10-31, openshift/release#45115). We could lift this restriction if we wanted to allow rollbacks to be requested from the middle of an in-progress update, but if we do, we'd probably want to add matching CI to cover that use-case. The new subcommand is hidden, as Lala requested in [2]'s Description on 2021-09-22. I have not put it behind a feature-gate environment variable in this commit, but that's also an option if we wanted to make it even less reachable. [1]: https://issues.redhat.com/browse/OTA-553 [2]: https://issues.redhat.com/browse/OTA-492
The "which release to roll back to?" criteria are matched to openshift/cluster-version-operator@12fdd0456b (pkg/payload/precondition/clusterversion/rollback: Allow previous version within z-stream, 2023-11-16, openshift/cluster-version-operator#996), where, based on [1], Lala, Scott, and Subin all agreed that rollbacks to the cluster's previous release should not be blocked, as long as the previous and current version had the same major.minor version (i.e. "within a z-stream", using x.y.z naming for major.minor.patch). We agreed to ignore whether the previous history entry is Completed or Partial, expecting that most users who are interested in rolling back will make that decision at the first sign of trouble, and not after attempting a few roll-forward retargets. I'm currently blocking Progressing!=False from rolling back, to align with our CI coverage in openshift/release@f4d37e7f87 (ci-operator/config/openshift/release: Use abort-at=100 for rollback-oldest-supported, 2023-10-31, openshift/release#45115). We could lift this restriction if we wanted to allow rollbacks to be requested from the middle of an in-progress update, but if we do, we'd probably want to add matching CI to cover that use-case. The new subcommand is hidden, as Lala requested in [2]'s Description on 2021-09-22. I have not put it behind a feature-gate environment variable in this commit, but that's also an option if we wanted to make it even less reachable. [1]: https://issues.redhat.com/browse/OTA-553 [2]: https://issues.redhat.com/browse/OTA-492
The "which release to roll back to?" criteria are matched to openshift/cluster-version-operator@12fdd0456b (pkg/payload/precondition/clusterversion/rollback: Allow previous version within z-stream, 2023-11-16, openshift/cluster-version-operator#996), where, based on [1], Lala, Scott, and Subin all agreed that rollbacks to the cluster's previous release should not be blocked, as long as the previous and current version had the same major.minor version (i.e. "within a z-stream", using x.y.z naming for major.minor.patch). We agreed to ignore whether the previous history entry is Completed or Partial, expecting that most users who are interested in rolling back will make that decision at the first sign of trouble, and not after attempting a few roll-forward retargets. I'm currently blocking Progressing!=False from rolling back, to align with our CI coverage in openshift/release@f4d37e7f87 (ci-operator/config/openshift/release: Use abort-at=100 for rollback-oldest-supported, 2023-10-31, openshift/release#45115). We could lift this restriction if we wanted to allow rollbacks to be requested from the middle of an in-progress update, but if we do, we'd probably want to add matching CI to cover that use-case. The new subcommand is hidden, as Lala requested in [2]'s Description on 2021-09-22. I have not put it behind a feature-gate environment variable in this commit, but that's also an option if we wanted to make it even less reachable. [1]: https://issues.redhat.com/browse/OTA-553 [2]: https://issues.redhat.com/browse/OTA-492
|
Fix included in accepted release 4.16.0-0.nightly-2024-01-09-085011 |
From OTA-553, Lala, Scott, and Subin all agreed that rollbacks to the cluster's previous release should not be blocked, as long as the previous and current version had the same
major.minorversion (i.e. "within a z-stream", usingx.y.znaming formajor.minor.patch). We agreed to ignore whether the previous history entry isCompletedorPartial, expecting that most users who are interested in rolling back will make that decision at the first sign of trouble, and not after attempting a few roll-forward retargets.