pkg/payload/precondition/clusterversion: Compare target metadata.previous, not rollback SemVer #967
Conversation
…ious, not rollback SemVer In 9ac845f (pkg/payload/precondition/clusterversion/rollback: New precondition, 2023-03-25, openshift#918), we grew a new precondition that parsed the current and target releases as semantic versions and rejected rollbacks. Admins could use 'force: true' to push through those (and other) guards, e.g. for testing purposes. However, we still lacked guards around SemVer increases, like 4.14.z hopping straight to 4.16. In most cases, customers will be using an OpenShift Update Service with a channel, and getting recommended updates they can use with 'oc adm upgrade --to ...' or the in-cluster web-console. But some clusters are not using update services. * ARO clusters are not subscribed to a channel by default and need to opt in [1]. * Some disconnected/restricted-network clusters currently use --to-image updates, although I personally think they would be safer running a local update services [2]. With this commit, I'm stiffening the previous guard to consume the previous-version metadata that's baked into release images [3] and consumed by Cincinnati when creating the update service responses [4]. This isn't as helpful as using an actual update service, because it will not include information about update risks we discover after building the release [5]. But it's still strictly stronger than the outgoing rollback-specific guard, and we haven't had to extend that previous-release list since the 4.1 release candidates [6]. [1]: https://learn.microsoft.com/en-us/azure/openshift/howto-upgrade#check-for-azure-red-hat-openshift-cluster-upgrades [2]: https://issues.redhat.com/browse/OTA-821 [3]: https://github.com/openshift/oc/blob/795bf1a6260847ecfc612da2ab11ea2d6e07da16/pkg/cli/admin/release/new.go#L135 [4]: https://github.com/openshift/cincinnati/blob/d77203d472ed5a7e00112c4d8265ba20f5034824/cincinnati/src/plugins/internal/graph_builder/release_scrape_dockerv2/registry/mod.rs#L419 [5]: https://github.com/openshift/cincinnati-graph-data#block-edges [6]: https://github.com/openshift/cincinnati-graph-data/blob/c09842556a9c5d3920f9f2d004e24b6fb2f3a2de/raw/metadata.json
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
|
[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
|
@wking: The following tests failed, say
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. |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
openshift-merge-robot
added
the
needs-rebase
|
PR needs rebase. 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. |
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
openshift-ci
bot
added
lifecycle/rotten
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closed this PR. DetailsIn 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. |
3 participants
In 9ac845f (#918), we grew a new precondition that parsed the current and target releases as semantic versions and rejected rollbacks. Admins could use 'force: true' to push through those (and other) guards, e.g. for testing purposes.
However, we still lacked guards around SemVer increases, like 4.14.z hopping straight to 4.16. In most cases, customers will be using an OpenShift Update Service with a channel, and getting recommended updates they can use with
oc adm upgrade --to ...or the in-cluster web-console. But some clusters are not using update services.--to-imageupdates, although I personally think they would be safer running a local update services.With this commit, I'm stiffening the previous guard to consume the previous-version metadata that's baked into release images and consumed by Cincinnati when creating the update service responses. This isn't as helpful as using an actual update service, because it will not include information about update risks we discover after building the release. But it's still strictly stronger than the outgoing rollback-specific guard, and we haven't had to extend that previous-release list since the 4.1 release candidates.