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.
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
Bug 1756453: Separate upgrade flags for safety instead of abusing force #109
Conversation
@abhinavdahiya you and I have discussed this, as part of ensuring 4.1 to 4.2 upgrades go smoothly we want to allow people in 4.1 to upgrade to 4.2 before we publish the edge without using --force to bypass content checks. |
14c741c
to
759750e
Compare
@smarterclayton: This pull request references Bugzilla bug 1756453, which is valid. The bug has been moved to the POST state. 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. |
pkg/cli/admin/upgrade/upgrade.go
Outdated
@@ -70,6 +78,8 @@ func New(f kcmdutil.Factory, parentName string, streams genericclioptions.IOStre | |||
flags.BoolVar(&o.ToLatestAvailable, "to-latest", o.ToLatestAvailable, "Use the next available version") | |||
flags.BoolVar(&o.Clear, "clear", o.Clear, "If an upgrade has been requested but not yet downloaded, cancel the update. This has no effect once the update has started.") | |||
flags.BoolVar(&o.Force, "force", o.Force, "Upgrade even if an upgrade is in process or other error is blocking update.") | |||
flags.BoolVar(&o.AllowExplicitUpgrade, "allow-explicit-upgrade", o.AllowExplicitUpgrade, "Upgrade even if the upgrade target is not listed in the available versions list.") | |||
flags.BoolVar(&o.AllowUnsafeUpgrade, "allow-unsafe-upgrade", o.AllowUnsafeUpgrade, "Upgrade even if an upgrade is in process or the cluster is error is blocking update.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
discussed changing this one to allow-upgrade-when-unhealthy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trying --allow-upgrade-with-warnings
?
fe67036
to
90be3d0
Compare
I like this. LGTM |
@smarterclayton: This pull request references Bugzilla bug 1756453, which is valid. 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One nit related to copy. LGTM
pkg/cli/admin/upgrade/upgrade.go
Outdated
@@ -70,6 +80,8 @@ func New(f kcmdutil.Factory, parentName string, streams genericclioptions.IOStre | |||
flags.BoolVar(&o.ToLatestAvailable, "to-latest", o.ToLatestAvailable, "Use the next available version") | |||
flags.BoolVar(&o.Clear, "clear", o.Clear, "If an upgrade has been requested but not yet downloaded, cancel the update. This has no effect once the update has started.") | |||
flags.BoolVar(&o.Force, "force", o.Force, "Upgrade even if an upgrade is in process or other error is blocking update.") | |||
flags.BoolVar(&o.AllowExplicitUpgrade, "allow-explicit-upgrade", o.AllowExplicitUpgrade, "Upgrade even if the upgrade target is not listed in the available versions list.") | |||
flags.BoolVar(&o.AllowUpgradeWithWarnings, "allow-upgrade-with-warnings", o.AllowUpgradeWithWarnings, "Upgrade even if an upgrade is in process or the cluster is error is blocking update.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other potential colors for the shed:
--allow-unsound-upgrade
--allow-impatient-upgrade
There also this bug https://bugzilla.redhat.com/show_bug.cgi?id=1713263 that states that |
That is not expected, are you going to track that separately or want me to throw it in here? I don't have an issue doing that. |
just wanted to get the expectation esp if it covers the new flags too..., we are already tracking this and we will work to fix it separately. |
The --force flag is dangerous and potentially allows untrusted content to be upgraded to accidentally. Instead, introduce two new flags `--allow-explicit-upgrade` (for upgrading to something not in availableVersions) and `--allow-upgrade-with-warnings` (for upgrading when another upgrade is in progress or the cluster is reporting an error) and remove those checks from `--force`. While this is an API change, it is necessary to ensure that users do not accidentally get access to untrusted content when performing upgrades across major versions in advance of graph updates, or when they are upgrading in disconnected environments.
90be3d0
to
0501d04
Compare
/retest |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jwforres, smarterclayton 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 |
/retest
…On Fri, Oct 4, 2019 at 1:40 PM OpenShift CI Robot ***@***.***> wrote:
@smarterclayton <https://github.com/smarterclayton>: The following test
*failed*, say /retest to rerun them all:
Test name Commit Details Rerun command
ci/prow/e2e-cmd 0501d04
<0501d04>
link
<https://prow.svc.ci.openshift.org/view/gcs/origin-ci-test/pr-logs/pull/openshift_oc/109/pull-ci-openshift-oc-master-e2e-cmd/108> /test
e2e-cmd
Full PR test history
<https://prow.svc.ci.openshift.org/pr-history?org=openshift&repo=oc&pr=109>.
Your PR dashboard
<https://prow.svc.ci.openshift.org/pr?query=is:pr+state:open+author:smarterclayton>.
Please help us cut down on flakes by linking to
<https://github.com/kubernetes/community/blob/master/contributors/devel/flaky-tests.md#filing-issues-for-flaky-tests>
an open issue <https://github.com/openshift/oc/issues?q=is:issue+is:open>
when you hit one in your PR.
Instructions for interacting with me using PR comments are available here
<https://git.k8s.io/community/contributors/guide/pull-requests.md>. If
you have questions or suggestions related to my behavior, please file an
issue against the kubernetes/test-infra
<https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:>
repository. I understand the commands that are listed here
<https://go.k8s.io/bot-commands>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#109?email_source=notifications&email_token=AAI37J5QLEPXAZUT4KQPWFDQM55YXA5CNFSM4I3IKMLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAMMGFA#issuecomment-538493716>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAI37J734JBQFQFA76O67NLQM55YXANCNFSM4I3IKMLA>
.
|
/retest |
/retest Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
/retest Please review the full test history for this PR and help us cut down flakes. |
@smarterclayton: All pull requests linked via external trackers have merged. Bugzilla bug 1756453 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. |
The warning is from cd30f2f (Add `oc adm upgrade` to display available updates or trigger an update, 2018-12-04), but the "does not check for upgrade compatibility..." portion is stale since 0501d04 (upgrade: Separate flags for safety instead of abusing force, 2019-09-27, openshift#109) added --allow-explicit-upgrade.
The warning is from cd30f2f (Add `oc adm upgrade` to display available updates or trigger an update, 2018-12-04), but the "does not check for upgrade compatibility..." portion is stale since 0501d04 (upgrade: Separate flags for safety instead of abusing force, 2019-09-27, openshift#109) added --allow-explicit-upgrade. Also fixes an unrelated "next available" -> "latest available" for --to-latest, fixing a typo from the history-breaking 3abf60a (setup oc repo, 2019-06-17).
The outgoing text is unchanged since the property landed ab4ff93 (Update ClusterVersion to have a 'force' update flag and track verified, 2019-04-22, openshift#293). Those docs fit on the 'oc' client side until openshift/oc@0501d04ff1 (upgrade: Separate flags for safety instead of abusing force, 2019-09-27, openshift/oc#109), but never applied to the cluster-version operator (CVO) side or the ClusterVersion type. The CVO uses Force to bypass verification failures [1] (invalid pullspec [2], lack of trusted signature [3], etc.) or preconditions [4] (ClusterVersion had Upgradeable=False for a requested minor bump [5]). [1]: https://github.com/openshift/cluster-version-operator/blob/28e4400eeb9ded7e09ff684e75780599cb25ec2c/pkg/cvo/updatepayload.go#L91-L102 [2]: https://github.com/openshift/cluster-version-operator/blob/28e4400eeb9ded7e09ff684e75780599cb25ec2c/pkg/verify/verify.go#L138 [3]: https://github.com/openshift/cluster-version-operator/blob/28e4400eeb9ded7e09ff684e75780599cb25ec2c/pkg/verify/verify.go#L182 [4]: https://github.com/openshift/cluster-version-operator/blob/28e4400eeb9ded7e09ff684e75780599cb25ec2c/pkg/cvo/sync_worker.go#L527-L529 [5]: https://github.com/openshift/cluster-version-operator/blob/28e4400eeb9ded7e09ff684e75780599cb25ec2c/pkg/payload/precondition/clusterversion/upgradeable.go#L74-L79
The outgoing text is unchanged since the property landed ab4ff93 (Update ClusterVersion to have a 'force' update flag and track verified, 2019-04-22, openshift#293). Those docs fit on the 'oc' client side until openshift/oc@0501d04ff1 (upgrade: Separate flags for safety instead of abusing force, 2019-09-27, openshift/oc#109), but never applied to the cluster-version operator (CVO) side or the ClusterVersion type. The CVO uses Force to bypass verification failures [1] (invalid pullspec [2], lack of trusted signature [3], etc.) or preconditions [4] (ClusterVersion had Upgradeable=False for a requested minor bump [5]). availableUpdates is orthogonal. I don't know what "other forms of consistency checking" was about, so I've dropped that too. If folks want to call out explicit categories that cannot be overridden with Force, we should do that with less ambiguous wording. [1]: https://github.com/openshift/cluster-version-operator/blob/28e4400eeb9ded7e09ff684e75780599cb25ec2c/pkg/cvo/updatepayload.go#L91-L102 [2]: https://github.com/openshift/cluster-version-operator/blob/28e4400eeb9ded7e09ff684e75780599cb25ec2c/pkg/verify/verify.go#L138 [3]: https://github.com/openshift/cluster-version-operator/blob/28e4400eeb9ded7e09ff684e75780599cb25ec2c/pkg/verify/verify.go#L182 [4]: https://github.com/openshift/cluster-version-operator/blob/28e4400eeb9ded7e09ff684e75780599cb25ec2c/pkg/cvo/sync_worker.go#L527-L529 [5]: https://github.com/openshift/cluster-version-operator/blob/28e4400eeb9ded7e09ff684e75780599cb25ec2c/pkg/payload/precondition/clusterversion/upgradeable.go#L74-L79
The outgoing text is unchanged since the property landed ab4ff93 (Update ClusterVersion to have a 'force' update flag and track verified, 2019-04-22, openshift#293). Those docs fit on the 'oc' client side until openshift/oc@0501d04ff1 (upgrade: Separate flags for safety instead of abusing force, 2019-09-27, openshift/oc#109), but never applied to the cluster-version operator (CVO) side or the ClusterVersion type. The CVO uses Force to bypass verification failures [1] (invalid pullspec [2], lack of trusted signature [3], etc.) or preconditions [4] (ClusterVersion had Upgradeable=False for a requested minor bump [5]). availableUpdates is orthogonal. I don't know what "other forms of consistency checking" was about, so I've dropped that too. If folks want to call out explicit categories that cannot be overridden with Force, we should do that with less ambiguous wording. Autogenerated bumps via: $ hack/update-swagger-docs.sh $ make update-codegen-crds [1]: https://github.com/openshift/cluster-version-operator/blob/28e4400eeb9ded7e09ff684e75780599cb25ec2c/pkg/cvo/updatepayload.go#L91-L102 [2]: https://github.com/openshift/cluster-version-operator/blob/28e4400eeb9ded7e09ff684e75780599cb25ec2c/pkg/verify/verify.go#L138 [3]: https://github.com/openshift/cluster-version-operator/blob/28e4400eeb9ded7e09ff684e75780599cb25ec2c/pkg/verify/verify.go#L182 [4]: https://github.com/openshift/cluster-version-operator/blob/28e4400eeb9ded7e09ff684e75780599cb25ec2c/pkg/cvo/sync_worker.go#L527-L529 [5]: https://github.com/openshift/cluster-version-operator/blob/28e4400eeb9ded7e09ff684e75780599cb25ec2c/pkg/payload/precondition/clusterversion/upgradeable.go#L74-L79
These docs have not been adjusted since the properties landed in ab4ff93 (Update ClusterVersion to have a 'force' update flag and track verified, 2019-04-22, openshift#293). The initial cluster-version operator implementation only used them for signature checks, openshift/cluster-version-operator@f8eff25191 (sync: Report whether updates are verified and allow admin override, 2019-04-20, openshift/cluster-version-operator#170). At that time, RetrievePayload would always attempt to verify the proposed release image, including both signature validation and "does this look like a real release image?" checks. If that verification succeeded, it would set 'verified: true'. If that verification failed, it would look at 'force', and if 'force' was true, it would set 'verified: false' and proceed with the update, while if 'force' was false, it would reject the update. Despite the API docs, availableUpdates never came into this in the CVO code. The only availableUpdates guards are client-side in 'oc', and the API docs are discussion the ClusterVersion API, not 'oc adm upgrade's --force API. In openshift/oc@0501d04ff1 (upgrade: Separate flags for safety instead of abusing force, 2019-09-27, openshift/oc#109), oc's client-side guards split --allow-explicit-upgrade (for updating to something not in availableUpdates) and --allow-upgrade-with-warnings (for updating despite client-side guards against Progressing and Degraded ClusterVersion conditions) away from --force, but again, never part of the ClusterVersion force property's CVO-side handling. Since then, the CVO grew precondition handlers in openshift/cluster-version-operator@aceb5bc66f (pkg: add precondition handlers and perform these checks before accepting Update, 2019-08-26, openshift/cluster-version-operator#243). syncOnce ran all the precondition checks, which at that point was just the Upgradeable ClusterOperator and ClusterVersion condition check. If that check failed, but 'force' was true, it would proceed with the update, while if 'force' was false, it would reject the update. In neither case would 'verified' be altered, it continued to only track the signature and "does this look like a real release image?" checks. The idea at the time was that these would fall under the "normal protections" phrasing (overriden by force) and not the "other forms of consistency checking" phrasing (whatever those were supposed to be).
These docs have not been adjusted since the properties landed in ab4ff93 (Update ClusterVersion to have a 'force' update flag and track verified, 2019-04-22, openshift#293). The initial cluster-version operator implementation only used them for signature checks, openshift/cluster-version-operator@f8eff25191 (sync: Report whether updates are verified and allow admin override, 2019-04-20, openshift/cluster-version-operator#170). At that time, RetrievePayload would always attempt to verify the proposed release image, including both signature validation and "does this look like a real release image?" checks. If that verification succeeded, it would set 'verified: true'. If that verification failed, it would look at 'force', and if 'force' was true, it would set 'verified: false' and proceed with the update, while if 'force' was false, it would reject the update. Despite the API docs, availableUpdates never came into this in the CVO code. The only availableUpdates guards are client-side in 'oc', and the API docs are discussion the ClusterVersion API, not 'oc adm upgrade's --force API. In openshift/oc@0501d04ff1 (upgrade: Separate flags for safety instead of abusing force, 2019-09-27, openshift/oc#109), oc's client-side guards split --allow-explicit-upgrade (for updating to something not in availableUpdates) and --allow-upgrade-with-warnings (for updating despite client-side guards against Progressing and Degraded ClusterVersion conditions) away from --force, but again, never part of the ClusterVersion force property's CVO-side handling. Since then, the CVO grew precondition handlers in openshift/cluster-version-operator@aceb5bc66f (pkg: add precondition handlers and perform these checks before accepting Update, 2019-08-26, openshift/cluster-version-operator#243). syncOnce ran all the precondition checks, which at that point was just the Upgradeable ClusterOperator and ClusterVersion condition check. If that check failed, but 'force' was true, it would proceed with the update, while if 'force' was false, it would reject the update. In neither case would 'verified' be altered; it continued to only track the signature and "does this look like a real release image?" checks. The idea at the time was that these would fall under the "normal protections" phrasing (overriden by force) and not the "other forms of consistency checking" phrasing (whatever those were supposed to be).
These docs have not been adjusted since the properties landed in ab4ff93 (Update ClusterVersion to have a 'force' update flag and track verified, 2019-04-22, openshift#293). The initial cluster-version operator implementation only used them for signature checks, openshift/cluster-version-operator@f8eff25191 (sync: Report whether updates are verified and allow admin override, 2019-04-20, openshift/cluster-version-operator#170). At that time, RetrievePayload would always attempt to verify the proposed release image, including both signature validation and "does this look like a real release image?" checks. If that verification succeeded, it would set 'verified: true'. If that verification failed, it would look at 'force', and if 'force' was true, it would set 'verified: false' and proceed with the update, while if 'force' was false, it would reject the update. Despite the API docs, availableUpdates never came into this in the CVO code. The only availableUpdates guards are client-side in 'oc', and the API docs are discussion the ClusterVersion API, not 'oc adm upgrade's --force API. In openshift/oc@0501d04ff1 (upgrade: Separate flags for safety instead of abusing force, 2019-09-27, openshift/oc#109), oc's client-side guards split --allow-explicit-upgrade (for updating to something not in availableUpdates) and --allow-upgrade-with-warnings (for updating despite client-side guards against Progressing and Degraded ClusterVersion conditions) away from --force, but again, never part of the ClusterVersion force property's CVO-side handling. Since then, the CVO grew precondition handlers in openshift/cluster-version-operator@aceb5bc66f (pkg: add precondition handlers and perform these checks before accepting Update, 2019-08-26, openshift/cluster-version-operator#243). syncOnce ran all the precondition checks, which at that point was just the Upgradeable ClusterOperator and ClusterVersion condition check. If that check failed, but 'force' was true, it would proceed with the update, while if 'force' was false, it would reject the update. In neither case would 'verified' be altered; it continued to only track the signature and "does this look like a real release image?" checks. The idea at the time was that these would fall under the "normal protections" phrasing (overriden by force) and not the "other forms of consistency checking" phrasing (whatever those were supposed to be).
These docs have not been adjusted since the properties landed in ab4ff93 (Update ClusterVersion to have a 'force' update flag and track verified, 2019-04-22, openshift#293). The initial cluster-version operator implementation only used them for signature checks, openshift/cluster-version-operator@f8eff25191 (sync: Report whether updates are verified and allow admin override, 2019-04-20, openshift/cluster-version-operator#170). At that time, RetrievePayload would always attempt to verify the proposed release image, including both signature validation and "does this look like a real release image?" checks. If that verification succeeded, it would set 'verified: true'. If that verification failed, it would look at 'force', and if 'force' was true, it would set 'verified: false' and proceed with the update, while if 'force' was false, it would reject the update. Despite the API docs, availableUpdates never came into this in the CVO code. The only availableUpdates guards are client-side in 'oc', and the API docs are discussion the ClusterVersion API, not 'oc adm upgrade's --force API. In openshift/oc@0501d04ff1 (upgrade: Separate flags for safety instead of abusing force, 2019-09-27, openshift/oc#109), oc's client-side guards split --allow-explicit-upgrade (for updating to something not in availableUpdates) and --allow-upgrade-with-warnings (for updating despite client-side guards against Progressing and Degraded ClusterVersion conditions) away from --force, but again, never part of the ClusterVersion force property's CVO-side handling. Since then, the CVO grew precondition handlers in openshift/cluster-version-operator@aceb5bc66f (pkg: add precondition handlers and perform these checks before accepting Update, 2019-08-26, openshift/cluster-version-operator#243). syncOnce ran all the precondition checks, which at that point was just the Upgradeable ClusterOperator and ClusterVersion condition check. If that check failed, but 'force' was true, it would proceed with the update, while if 'force' was false, it would reject the update. In neither case would 'verified' be altered; it continued to only track the signature and "does this look like a real release image?" checks. The idea at the time was that these would fall under the "normal protections" phrasing (overriden by force) and not the "other forms of consistency checking" phrasing (whatever those were supposed to be).
These docs have not been adjusted since the properties landed in ab4ff93 (Update ClusterVersion to have a 'force' update flag and track verified, 2019-04-22, openshift#293). The initial cluster-version operator implementation only used them for signature checks, openshift/cluster-version-operator@f8eff25191 (sync: Report whether updates are verified and allow admin override, 2019-04-20, openshift/cluster-version-operator#170). At that time, RetrievePayload would always attempt to verify the proposed release image, including both signature validation and "does this look like a real release image?" checks. If that verification succeeded, it would set 'verified: true'. If that verification failed, it would look at 'force', and if 'force' was true, it would set 'verified: false' and proceed with the update, while if 'force' was false, it would reject the update. Despite the API docs, availableUpdates never came into this in the CVO code. The only availableUpdates guards are client-side in 'oc', and the API docs are discussion the ClusterVersion API, not 'oc adm upgrade's --force API. In openshift/oc@0501d04ff1 (upgrade: Separate flags for safety instead of abusing force, 2019-09-27, openshift/oc#109), oc's client-side guards split --allow-explicit-upgrade (for updating to something not in availableUpdates) and --allow-upgrade-with-warnings (for updating despite client-side guards against Progressing and Degraded ClusterVersion conditions) away from --force, but again, never part of the ClusterVersion force property's CVO-side handling. Since then, the CVO grew precondition handlers in openshift/cluster-version-operator@aceb5bc66f (pkg: add precondition handlers and perform these checks before accepting Update, 2019-08-26, openshift/cluster-version-operator#243). syncOnce ran all the precondition checks, which at that point was just the Upgradeable ClusterOperator and ClusterVersion condition check. If that check failed, but 'force' was true, it would proceed with the update, while if 'force' was false, it would reject the update. In neither case would 'verified' be altered; it continued to only track the signature and "does this look like a real release image?" checks. The idea at the time was that these would fall under the "normal protections" phrasing (overriden by force) and not the "other forms of consistency checking" phrasing (whatever those were supposed to be).
We've had the warning at least since this repo was created in 3abf60a (setup oc repo, 2019-06-17). But since we grew --allow-explicit-upgrade in 0501d04 (upgrade: Separate flags for safety instead of abusing force, 2019-09-27, openshift#109), --to-image has been just as restricted to recommended updates as --to. Removing the warning here avoids uneccessary alarm. We can save the warning for --allow-explicit-upgrade, whose help text I'm consolidating in this commit. The new structure is: * --to and --to-image together, since in the absecne of --allow-explicit-upgrade those are equally safe. * The paragraph about unsupported updates or broken CVO <-> upstream update service communication. Before this paragraph had focused on --to-image, but I've adjusted it to focus on --allow-explicit-upgrade. * The --allow-upgrade-with-warnings paragraph. I've moved the sentence about retargeting updates over to this paragraph, since --allow-upgrade-with-warnings is the relevant flag for that issue. * The --force paragraph, because that's about a cluster-side check that occurs after the oc-side --allow-* checks, so having it last in the help text gives us the same order in help as we get for check application.
We've had the warning at least since this repo was created in 3abf60a (setup oc repo, 2019-06-17). But since we grew --allow-explicit-upgrade in 0501d04 (upgrade: Separate flags for safety instead of abusing force, 2019-09-27, openshift#109), --to-image has been just as restricted to recommended updates as --to. Removing the warning here avoids unnecessary alarm. We can save the warning for --allow-explicit-upgrade, whose help text I'm consolidating in this commit. The new structure is: * --to and --to-image together, since in the absence of --allow-explicit-upgrade those are equally safe. * The paragraph about unsupported updates or broken CVO <-> upstream update service communication. Before this paragraph had focused on --to-image, but I've adjusted it to focus on --allow-explicit-upgrade. * The --allow-upgrade-with-warnings paragraph. I've moved the sentence about retargeting updates over to this paragraph, since --allow-upgrade-with-warnings is the relevant flag for that issue. * The --force paragraph, because that's about a cluster-side check that occurs after the oc-side --allow-* checks, so having it last in the help text gives us the same order in help as we get for check application.
We've had the warning at least since this repo was created in 3abf60a (setup oc repo, 2019-06-17). But since we grew --allow-explicit-upgrade in 0501d04 (upgrade: Separate flags for safety instead of abusing force, 2019-09-27, openshift#109), --to-image has been just as restricted to recommended updates as --to. Removing the warning here avoids unnecessary alarm. We can save the warning for --allow-explicit-upgrade, whose help text I'm consolidating in this commit. The new structure is: * --to and --to-image together, since in the absence of --allow-explicit-upgrade those are equally safe. * The paragraph about unsupported updates or broken CVO <-> upstream update service communication. Before this paragraph had focused on --to-image, but I've adjusted it to focus on --allow-explicit-upgrade. * The --allow-upgrade-with-warnings paragraph. I've moved the sentence about retargeting updates over to this paragraph, since --allow-upgrade-with-warnings is the relevant flag for that issue. * The --force paragraph, because that's about a cluster-side check that occurs after the oc-side --allow-* checks, so having it last in the help text gives us the same order in help as we get for check application.
The --force flag is dangerous and potentially allows untrusted content to be upgraded to accidentally. Instead, introduce two new flags
--allow-explicit-upgrade
(for upgrading to something not in availableVersions) and--allow-upgrade-with-warnings
(for upgrading when another upgrade is in progress or the cluster is reporting an error) and remove those checks from--force
.While this is an API change, it is necessary to ensure that users do not accidentally get access to untrusted content when performing upgrades across major versions in advance of graph updates, or when they are upgrading in disconnected environments.
/assign @jwforres
@eparis as discussed today
This should be a candidate for backport to 4.2 and 4.1. While it changes flag behavior, it will only break things in a "safe" way. This addresses a significant security challenge as we have introduced new meanings for --force.