openshift-ci-robot
commented
2 weeks ago @wking: This pull request references Jira Issue OCPBUGS-35994, which is valid. The bug has been moved to the POST state.
3 validation(s) were run on this bug
* bug is open, matching expected state (open) * bug target version (4.17.0) matches configured target version for branch (4.17.0) * bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)Requesting review from QA contact: /cc @jiajliu
The bug has been updated to refer to the pull request using the external bug tracker.
In response to [this](https://github.com/openshift/oc/pull/1806):
>Current CI/QE capacity doesn't have space to support rollbacks, which require basically the same level of effort as supporting roll-forward updates, but which would never be used by as many clusters as the number of clusters that use roll-forward updates. In addition, paused MachineConfigPools and HyperShift's NodePools and similar allow for decoupling compute updates from control-plane updates. And control-plane updates have PodDisruptionBudgets and such to wedge gracefully if an issue comes up during updates that destabilizes the control plane. And if a control-plane update goes smoothly, but its behavior changes destabilize cluster workloads, ClusterVersion overrides and similar give an emergency safety valve to patch things up while admins wait for new releases that address the newly-discovered issues, while [conditional updates][1] allow the risk to be declared so additional clusters are warned before attempting an exposed update.
>
>With the moderate operational benefit weighted against the substantial cost of CI/QE test coverage, this commit reverts the subcommand which I'd initially added in 73074c32ba (#1642) and gated in 9b2842a0c9 (#1764).
>
>[1]: https://github.com/openshift/enhancements/blob/0977611b030fcb667b22cdf36a86e3852ee54e84/enhancements/update/targeted-update-edge-blocking.md
Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=openshift%2Foc). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
petr-muller
evakhoni
wking
openshift-ci[bot]
Current CI/QE capacity doesn't have space to support rollbacks, which require basically the same level of effort as supporting roll-forward updates, but which would never be used by as many clusters as the number of clusters that use roll-forward updates. In addition, paused MachineConfigPools and HyperShift's NodePools and similar allow for decoupling compute updates from control-plane updates. And control-plane updates have PodDisruptionBudgets and such to wedge gracefully if an issue comes up during updates that destabilizes the control plane. And if a control-plane update goes smoothly, but its behavior changes destabilize cluster workloads, ClusterVersion overrides and similar give an emergency safety valve to patch things up while admins wait for new releases that address the newly-discovered issues, while conditional updates allow the risk to be declared so additional clusters are warned before attempting an exposed update.
With the moderate operational benefit weighted against the substantial cost of CI/QE test coverage, this commit reverts the subcommand which I'd initially added in 73074c32ba (#1642) and gated in 9b2842a0c9 (#1764).