docs: Add snap upgrades how-to #934
Conversation
HomayoonAlimohammadi
force-pushed
the
KU-2420/snap-upgrades-how-to
branch
from
b1095aa to
4929fd7
Compare
HomayoonAlimohammadi
force-pushed
the
KU-2420/snap-upgrades-how-to
branch
from
4929fd7 to
c369bb0
Compare
| upgrading is not supported. For more details, please visit [Version Skew Policy][2]. | ||
| - Before performing an upgrade, it's important to back up the cluster data. | ||
| This can be done by following the steps outlined in the [backup guide][3]. | ||
| - For more info about managing snap updates, please refer to the [snap documentation][4]. |
There was a problem hiding this comment.
I would put this one last
| - Before performing an upgrade, it's important to back up the cluster data. | ||
| This can be done by following the steps outlined in the [backup guide][3]. | ||
| - For more info about managing snap updates, please refer to the [snap documentation][4]. | ||
| - Managing upgrades in a multi node cluster is a complex operation, and it's |
There was a problem hiding this comment.
I feel like this is misleading as someone may have deployed via snap and then think they can go to juju to upgrade their cluster. Maybe add a line about if have already deployed with snap only continue with this guide?
There was a problem hiding this comment.
+1 let's remove this line
|
|
||
| ## Patch Upgrade | ||
|
|
||
| Patch upgrades apply bug fixes and are generally safe without API changes. |
There was a problem hiding this comment.
Suggestion: Patch upgrades apply bug fixes, are generally safe and without API changes.
There was a problem hiding this comment.
Suggestion 2: Patch upgrades address bug fixes and are typically safe, introducing no breaking changes.
|
|
||
| 2. **Change the snap channel:** | ||
| The {{product}} snap channel can be changed either by using the `snap refresh` command or by using the `snap switch` command. | ||
| The main difference between these two methods is that `snap refresh` will update the snap to the latest revision in the new channel, while `snap switch` switches to the new channel without doing a refresh. |
There was a problem hiding this comment.
I am a bit confused on the difference. Does this mean the snap switch will go to the oldest version of the new channel automatically?
There was a problem hiding this comment.
snap switch will not actually update/refresh the snap but only change the track it follows.
Think of it like changing the origin of a git repository (without actually fetching).
There was a problem hiding this comment.
Maybe we should just explain one way of doing this (snap refresh) as snap switch is more of an edge case?
| snap info k8s | ||
| k8s status --wait-ready | ||
| ``` | ||
|
|
There was a problem hiding this comment.
Maybe add a line on how you need to do this for every snap node in the cluster
| @@ -26,6 +26,7 @@ two-node-ha | |||
| Set up Enhanced Platform Awareness <epa> | |||
| contribute | |||
| Get support <support> | |||
| Managing Upgrades <upgrades> | |||
| @@ -26,6 +26,7 @@ two-node-ha | |||
| Set up Enhanced Platform Awareness <epa> | |||
| contribute | |||
| Get support <support> | |||
| Managing Upgrades <upgrades> | |||
There was a problem hiding this comment.
I would also move this higher in the order. Maybe above epa
| ## Important Considerations Before Upgrading | ||
|
|
||
| - According to the [upstream Kubernetes][1], skipping **minor** versions while | ||
| upgrading is not supported. For more details, please visit [Version Skew Policy][2]. |
There was a problem hiding this comment.
| upgrading is not supported. For more details, please visit [Version Skew Policy][2]. | |
| upgrading is not supported. For more details, please visit the [Version Skew Policy][2]. |
| upgrading is not supported. For more details, please visit [Version Skew Policy][2]. | ||
| - Before performing an upgrade, it's important to back up the cluster data. | ||
| This can be done by following the steps outlined in the [backup guide][3]. | ||
| - For more info about managing snap updates, please refer to the [snap documentation][4]. |
There was a problem hiding this comment.
| - For more info about managing snap updates, please refer to the [snap documentation][4]. | |
| - For more information on managing snap updates, please refer to the [snap documentation][4]. |
| - Before performing an upgrade, it's important to back up the cluster data. | ||
| This can be done by following the steps outlined in the [backup guide][3]. | ||
| - For more info about managing snap updates, please refer to the [snap documentation][4]. | ||
| - Managing upgrades in a multi node cluster is a complex operation, and it's |
There was a problem hiding this comment.
+1 let's remove this line
| ## What you will need | ||
|
|
||
| - A running {{product}} cluster. |
There was a problem hiding this comment.
Let's remove this, it's a given.
| Patch upgrades apply bug fixes and are generally safe without API changes. | ||
| Snaps update automatically, and by default, the snapd daemon checks for updates 4 times a day. | ||
| {{product}} is installed using a specific track, which consists of a major and minor version. | ||
| As an example, if {{product}} is installed using the `1.32` track, | ||
| the snap updates automatically to the latest revision of `1.32` during daily checks. | ||
| Patch upgrades can also be triggered manually by following the steps below. |
There was a problem hiding this comment.
Can we please condense this information to about half?
| confirming that the cluster is ready: | ||
| ``` | ||
| snap info k8s | ||
| k8s status --wait-ready |
| ``` | ||
| snap refresh k8s --hold | ||
| ``` | ||
| Or |
There was a problem hiding this comment.
| Or | |
| Or specify a time window: |
There was a problem hiding this comment.
Looks good to me, minor comments
Great work @HomayoonAlimohammadi
|
|
||
| ## Patch Upgrade | ||
|
|
||
| Patch upgrades apply bug fixes and are generally safe without API changes. |
There was a problem hiding this comment.
Suggestion 2: Patch upgrades address bug fixes and are typically safe, introducing no breaking changes.
| ## Patch Upgrade | ||
|
|
||
| Patch upgrades apply bug fixes and are generally safe without API changes. | ||
| Snaps update automatically, and by default, the snapd daemon checks for updates 4 times a day. |
There was a problem hiding this comment.
This feels like an implemenatation detail of the Snap ecosystem.
Maybe:
Snaps automatically check for updates several times a day and apply them when available.
|
|
||
| 2. **Change the snap channel:** | ||
| The {{product}} snap channel can be changed either by using the `snap refresh` command or by using the `snap switch` command. | ||
| The main difference between these two methods is that `snap refresh` will update the snap to the latest revision in the new channel, while `snap switch` switches to the new channel without doing a refresh. |
There was a problem hiding this comment.
snap switch will not actually update/refresh the snap but only change the track it follows.
Think of it like changing the origin of a git repository (without actually fetching).
|
|
||
| 2. **Change the snap channel:** | ||
| The {{product}} snap channel can be changed either by using the `snap refresh` command or by using the `snap switch` command. | ||
| The main difference between these two methods is that `snap refresh` will update the snap to the latest revision in the new channel, while `snap switch` switches to the new channel without doing a refresh. |
There was a problem hiding this comment.
Maybe we should just explain one way of doing this (snap refresh) as snap switch is more of an edge case?
Overview
This PR adds a how-to guide on snap upgrades.