[Docs] Support rollback in zero-downtime incremental upgrade - #65249
[Docs] Support rollback in zero-downtime incremental upgrade#65249win5923 wants to merge 2 commits into
Conversation
There was a problem hiding this comment.
Code Review
This pull request updates the RayService incremental upgrade documentation to reflect its promotion from alpha to beta, adding detailed sections on rollback behavior, upgrade/rollback triggers, and new status conditions. The feedback suggests improving the clarity of the rollback documentation by replacing 'reverting' with 'resuming' in Case 2, and aligning the behavior of the RollbackInProgress condition with standard Kubernetes API design by setting it to False instead of removing it.
|
|
||
| Pipeline: `A -> B -> A` | ||
|
|
||
| **Case 2: `C == B` (reverting to the upgraded spec)** |
There was a problem hiding this comment.
+1 i'd say "cancel rollback" or "resume upgrading"
| | Condition | Description | | ||
| | :--- | :--- | | ||
| | `UpgradeInProgress` | `True` while both an active and a pending `RayCluster` exist for the `RayService`. KubeRay sets this condition to `False` with reason `NoPendingCluster` after it promotes the pending cluster, or after a rollback finishes and it deletes the pending cluster. | | ||
| | `RollbackInProgress` | `True` while KubeRay is rolling an in-progress incremental upgrade back to the original active cluster, with reason `DesiredClusterSpecChanged`. KubeRay removes this condition when the rollback completes, or when you revert the spec back to the pending cluster's spec to cancel the rollback. | |
There was a problem hiding this comment.
In Kubernetes, status conditions are typically set to False rather than being entirely removed from the status list, which helps preserve transition history. The description for UpgradeInProgress correctly states that KubeRay sets it to False. For consistency and standard Kubernetes API design, please clarify if RollbackInProgress is also set to False instead of being removed.
|
cc @ryanaoleary to take a look when you have time. |
Signed-off-by: win5923 <ken89@kimo.com>
|
|
||
| **Case 1: `C == A` (reverting to the original spec)** | ||
|
|
||
| The controller cancels the upgrade and gradually shifts traffic back to the original cluster, scaling its `targetCapacity` back to 100% while scaling the pending cluster down to 0%, then deletes the pending cluster. |
There was a problem hiding this comment.
nit: specify it's scaling back by stepSizePercent
| | Condition | Description | | ||
| | :--- | :--- | | ||
| | `UpgradeInProgress` | `True` while both an active and a pending `RayCluster` exist for the `RayService`. KubeRay sets this condition to `False` with reason `NoPendingCluster` after it promotes the pending cluster, or after a rollback finishes and it deletes the pending cluster. | | ||
| | `RollbackInProgress` | `True` while KubeRay is rolling an in-progress incremental upgrade back to the original active cluster, with reason `DesiredClusterSpecChanged`. KubeRay removes this condition when the rollback completes, or when you revert the spec back to the pending cluster's spec to cancel the rollback. | |
There was a problem hiding this comment.
could specify rollback "completes" when traffic has fully migrated and the old cluster is cleared
ryanaoleary
left a comment
There was a problem hiding this comment.
some small nit comments, overall doc update LGTM
Signed-off-by: win5923 <ken89@kimo.com>
Description
Starting with KubeRay v1.7, incremental upgrade has reached Beta and supports rollback.
Doc Link: https://anyscale-ray--65249.com.readthedocs.build/en/65249/cluster/kubernetes/user-guides/rayservice-incremental-upgrade.html
Related issues
ray-project/kuberay#4781
Additional information