-
Notifications
You must be signed in to change notification settings - Fork 40
Added the table for clusters and methods for upgrade #859
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
Conversation
Signed-off-by: Ranjini M N <[email protected]>
|
@hardys and @e-minguez I created the table based on the information provided. |
Also
|
|
@e-minguez Okay. I will also wait for @hardys inputs on this before I make any changes. |
|
lgtm but looks like the branch needs a rebase? |
Signed-off-by: Ranjini M N <[email protected]>
Signed-off-by: Ranjini M N <[email protected]>
Signed-off-by: Ranjini M N <[email protected]>
Signed-off-by: Ranjini M N <[email protected]>
Signed-off-by: Ranjini M N <[email protected]>
Signed-off-by: Ranjini M N <[email protected]>
Signed-off-by: Ranjini M N <[email protected]>
Signed-off-by: Ranjini M N <[email protected]>
#829
I have created the table as per the description provided.
For downstream clusters, we have (at least) 3 different scenarios, and each of them involve different upgrade procedures/mechanisms. AFAIK:
For EIB provisioned clusters -> Fleet approach
For Metal3 provisioned clusters -> Redeploy with a fresh image
For phone-home provisioned clusters -> K8s upgrade via rancher + SUC for the OS and everything else
It would be nice to have a table/matrix/something to explicitly clarify each scenario.