other available 4.2 update changes #16895
Conversation
openshift-ci-robot
added
the
size/S
|
The preview will be available shortly at: |
modules/update-upgrading-web.adoc
Outdated
There was a problem hiding this comment.
Major (e.g. 4.9.10->5.0.0), minor (e.g. 4.1.9->4.2.3), and patch (e.g. 4.1.9->4.1.11)?
There was a problem hiding this comment.
And in case we are disagreeing on terms, my major.minor.patch terms are from https://semver.org/spec/v2.0.0.html#summary
There was a problem hiding this comment.
Your terminology is better than mine. I'll update it.
modules/update-upgrading-web.adoc
Outdated
There was a problem hiding this comment.
Is {major.minor_version} a thing? Would be nice if you didn't have to bump this manually, but could get it automatically expanded to match whatever flavor the docs were being built for.
There was a problem hiding this comment.
It's not. I think that it's a good idea though, so I'm going to bring it through our internal change process.
updating/updating-cluster-cli.adoc
Outdated
There was a problem hiding this comment.
You can tell your cluster to upgrade to whatever version using oc adm upgrade .... But telling it to take upgrades that aren't in our official Cincinnati graph (e.g. https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.1 ) may be unsupported. I'm not clear on the official support policy in this space; maybe @crawford knows?
There was a problem hiding this comment.
It's unsupported. We really need to teach the CVO to do local validation as well so it's less easy to make that mistake.
There was a problem hiding this comment.
We really need to teach the CVO to do local validation as well so it's less easy to make that mistake.
The CVO may already refuse non graph upgrades without --force. But I was previously not clear on whether that override voided support for the cluster. Even more reason to track edge removal in Git ;).
There was a problem hiding this comment.
I'll clarify that you can only update within the current minor version, but I'm not going to mention that they can make an unsupported update by using --force.
There was a problem hiding this comment.
I'll clarify that you can only update within the current minor version...
Until we start recommending 4.1->4.2 upgrades.
... but I'm not going to mention that they can make an unsupported update by using
--force.
But disconnected folks will have to do this, because the CVO cannot pull their signatures to validate them.
On the other hand, without --force it should be impossible to make an unsupported upgrade.
There was a problem hiding this comment.
I'll clarify that you can only update within the current minor version...
Until we start recommending 4.1->4.2 upgrades.
Clayton said that the best user experience was to upgrade 4.1 > 4.2 updates from the web console, so that's the only path I'm going to document.
... but I'm not going to mention that they can make an unsupported update by using
--force.But disconnected folks will have to do this, because the CVO cannot pull their signatures to validate them.
On the other hand, without
--forceit should be impossible to make an unsupported upgrade.
The disconnected update path will have its own separate topic after all my in-flight PRs merge.
updating/updating-cluster-cli.adoc
Outdated
There was a problem hiding this comment.
Without --force, you have the same choices as in the web UI, and you can see those choices with oc adm upgrade. From oc adm upgrade --help:
If no arguments are passed the command will retrieve the current version info and display whether an upgrade is in progress or whether any errors might prevent an upgrade, as well as show the suggested updates available to the cluster.
There was a problem hiding this comment.
Did Clayton change his mind about the web UI being the best user experience for updates between versions? I thought that you couldn't change the channel.
There was a problem hiding this comment.
Did Clayton change his mind about the web UI being the best user experience for updates between versions?
I doubt it ;).
I thought that you couldn't change the channel.
You can oc patch ... like the examples here.
There was a problem hiding this comment.
The UI is the best user experience because the cli doesn't have the tools to list/show you acceptable versions (maybe we should fix that)?
There was a problem hiding this comment.
I think that might be a good RFE. Along with the ability to easily retrieve and update the channels in the graph.
There was a problem hiding this comment.
The UI is the best user experience because the cli doesn't have the tools to list/show you acceptable versions...
oc adm upgrade should list recommend targets from the graph (via ClusterVersion.status`).
There was a problem hiding this comment.
[kalexand@localhost ~]$ oc adm upgrade
Cluster version is 4.1.20
No updates available. You may force an upgrade to a specific release image, but doing so may not be supported and result in downtime or data loss.
When is update going to be working as intended?
There was a problem hiding this comment.
I am happy to add the appropriate update docs as soon as we can identify the best user path and attempt to validate it.
There was a problem hiding this comment.
When is update going to be working as intended?
No recommended upgrades from 4.1.20 is appropriate now. What targets where you expecting to see? You can test the oc functionality by running against 4.1.18, which should show 4.1.20 if you are in stable-4.1 or prerelease-4.1.
There was a problem hiding this comment.
Ah, then we're still stuck because the question's about updating between minor versions not within a minor version.
|
@jiajliu, will you PTAL? |
kalexand-rh
force-pushed
the
update-4.2
branch
from
cb29851 to
6197dc7
Compare
openshift-ci-robot
added
size/M
|
@wking, will you PTAL at the latest commit? I addressed some of your feedback in Slack and added a topic about updating between minor versions. |
modules/update-upgrading-web.adoc
Outdated
There was a problem hiding this comment.
I dunno about rhel---7; when I visit https://access.redhat.com/downloads/content/290/ver=4.1/, I'm redirected to https://access.redhat.com/downloads/content/290/ver=4.1/rhel---8/4.1.18/x86_64/product-software .
Also, I'm not wild about pinning to 4.2.0, will that only show errata fixed by 4.2.0->4.2.1? Or will it show 4.2.0->4.2.{latest}?
And if we do pin to something in 4.2.z, you'll want ver=4.2, not ver=4.1.
There was a problem hiding this comment.
The errata page shows all of the changes for the minor release.
modules/update-upgrading-web.adoc
Outdated
There was a problem hiding this comment.
One hop does not guarantee you get to a good jumping-off point. For example, the current stable-4.1 graph is:
$ curl -sH 'Accept:application/json' 'https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.1' | ~/src/openshift/cincinnati/hack/graph.sh | dot -Tpng >graph.pngusing graph.sh to generate:
With 4.1.18 as a jumping-off point (as we're currently planning), folks on 4.2.0 would have to go 4.2.0->4.2.14->4.1.18 or similar. Anyone still running the guarded 4.1.10 would have to go 4.1.10->4.1.11->4.1.18 or similar. We probably want to say "and keep upgrading until there are no recommended upgrades left" somewhere for this use-case.
There was a problem hiding this comment.
Is there a better way to get that graph and see what updates are available? "and keep upgrading until there are no recommended upgrades left" isn't the best user experience.
There was a problem hiding this comment.
Not at the moment, but maybe in the mid-term. Eventual UX will be "turn on auto-upgrades, set your target channel, and we'll route you through the graph".
There was a problem hiding this comment.
When that's about to happen, please let me know.
modules/update-upgrading-web.adoc
Outdated
There was a problem hiding this comment.
"...and wait until the cluster-version operator refreshes the upgrade graph."? It would be nice if we were watching the ClusterVersion object and triggering a fresh fetch when the channel changed (and maybe we are), but even then, it might take some time to pull the graph, or the network could be down, or whatever. I think it's worth saying something to hint that into the reader's conciousness even if we don't take a big dive into all possible complications ;).
modules/update-upgrading-web.adoc
Outdated
There was a problem hiding this comment.
This sentence is not between-specific. Maybe it's best to leave the between-minor docs out of this module so it can stay focused on executing a single upgrade, and then have a different module or leading section on between-minors that says "to upgrade between minors, upgrade to the most recent release in your current channel by repeating {the upgrade proceedure} until you no longer have any available updates. Then change your channel to the new stable-* and perform the available update." Or something...
|
@jiajliu, will you PTAL? |
kalexand-rh
force-pushed
the
update-4.2
branch
from
86575d6 to
2de62ab
Compare
There was a problem hiding this comment.
Can i understand this "user can only upgrade to a minor version through web console"? why not cli supported in minor version upgrade?
and for a 4.1.z version, how user can upgrade the cluster to 4.2? i ask this because i did not see any available update for both 4.1.18 and 4.1.20 when set channel to stable-4.2?
There was a problem hiding this comment.
I've gotten conflicting messages about whether or not it's required to use --force from the CLI. After update between 4.1 and 4.2 is working as intended, I'm happy to revisit.
There's an ongoing discussion about how the update from 4.1.z to 4.2 is supposed to work on the sbr-shift-list, and I've asked Eric to let me know when there's a plan to move forward.
There was a problem hiding this comment.
We don't want customers forcing upgrades, we want them using the graphs we provide.
That said we need to document to customers how to use the force option, and clearly explain that its not a recommended decision to do this.
There was a problem hiding this comment.
Customers can update from cli or web console, the web console (or our Cincinnati graph are the ways you know what acceptable upgrades are).
There was a problem hiding this comment.
I'm happy to add some conceptual material and warnings about the existence of the --force option and emphasize the need to use one of the supported options in the graph. We're only adding steps that we actually want users to take. (If I add steps about how to use the --force option, you know people are going to follow them.)
There was a problem hiding this comment.
Can i understand this "user can only upgrade to a minor version through web console"? why not cli supported in minor version upgrade?
and for a 4.1.z version, how user can upgrade the cluster to 4.2? i ask this because i did not see any available update for both 4.1.18 and 4.1.20 when set channel to stable-4.2?
@jiajliu, Trevor and I talked about this for awhile. It's because you need to change channel from the stable-4.1 to a 4.2 channel to upgrade, and there's not a good way to do that in the CLI. Instead of changing channel in the UI and then swapping to the CLI to finish, we're just staying in the UI.
_topic_map.yml
Outdated
There was a problem hiding this comment.
i think this definition about minor version and within a minor version need to be unified.
in v4.1(https://docs.openshift.com/container-platform/4.1/updating/updating-cluster.html), minor version upgrade means 4.1.0-4.1.2,
but in this pr, seems minor version upgrade refer to 4.1-4.2.
There was a problem hiding this comment.
I'll open a separate PR to fix that language in 4.1.
There was a problem hiding this comment.
Here's the 4.1 only PR to change these titles: #17631
@kalexand-rh sorry for missing your msg, just add two comments in the pr. |
openshift-ci-robot
added
the
needs-rebase
kalexand-rh
force-pushed
the
update-4.2
branch
from
071aeb7 to
68ca5b7
Compare
openshift-ci-robot
removed
needs-rebase
|
@jiajliu, will you PTAL? Engineering wants this change to go live on Tuesday, and I'd like to address any of your concerns on Monday, if possible. |
|
@jiajliu, will you PTAL? I think that this content will be valid with tomorrow's errata release, and I want to get it live as soon as possible. |
kalexand-rh
force-pushed
the
update-4.2
branch
2 times, most recently
from
d7679aa to
e621425
Compare
kalexand-rh
added
the
peer-review-needed
|
@openshift/team-documentation, PTAL? |
bergerhoffer
left a comment
bergerhoffer
left a comment
There was a problem hiding this comment.
Just a few minor things
There was a problem hiding this comment.
Not critical, just wondering whether we try to avoid changing anchor links in a version after it's been released.
There was a problem hiding this comment.
It's an error that I regret not catching during peer review. There was a lot of drama in the mod docs repo over how much using malformed anchor IDS can break automation. There are also no other links to this content in the collection.
bergerhoffer
added
peer-review-done
|
/lgtm |
kalexand-rh
force-pushed
the
update-4.2
branch
from
e621425 to
71ad8c0
Compare
|
New changes are detected. LGTM label has been removed. |
|
Thanks! Merging. |
|
/cherrypick enterprise-4.2 |
|
/cherrypick enterprise-4.3 |
|
@kalexand-rh: new pull request created: #17754 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. |
|
@kalexand-rh: new pull request created: #17755 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. |
11 participants
@wking, does this sound right to you?