Conversation
Minor edits
peterschmidt85
left a comment
peterschmidt85
left a comment
There was a problem hiding this comment.
Made minor edits. All looks good!
docs/docs/concepts/services.md
Outdated
| <!-- NOTE: should be in sync with constants in server/services/runs.py --> | ||
|
|
||
| ??? info "Force a redeployment" | ||
| `dstack` automatically detects changes to `resources`, `volumes`, `docker`, `files`, `image`, `user`, `privileged`, `entrypoint`, `working_dir`, `python`, `nvcc`, `single_branch`, `env`, `shell`, `commands`, and to [repo](repos.md) and [files](#files) contents. |
There was a problem hiding this comment.
It detects changes to all properties, these are just the ones that can be updated using a rolling deployment
docs/docs/concepts/services.md
Outdated
| If `dstack` can apply all the detected changes without a full service restart, it starts a rolling deployment. During the rolling deployment, `dstack` gradually updates the service replicas to the new version. First, it starts an extra replica. Then, it waits until this replica enters the `running` state. Finally, it terminates the old replica. | ||
|
|
||
| During deployment, new and old replicas can coexist and handle requests simultaneously. If the service has multiple replicas, they are updated one by one — there can be at most one extra replica above the desired number of replicas, as determined by the `replicas` and `scaling` properties. |
There was a problem hiding this comment.
I think the algorithm description is worth keeping in the docs, so that users know what to expect during deployments and better understand what they are seeing in dstack apply
Minor edits
peterschmidt85
left a comment
peterschmidt85
left a comment
There was a problem hiding this comment.
Added minor edits. Looks good otherwise!
|
@jvstme Shall we merge? |
docs/docs/concepts/services.md
Outdated
| </div> | ||
|
|
||
| To update a replica, `dstack` starts a new replica, then waits until it becomes `running`, then terminates the old replica. If the service has multiple replicas, they are updated one by one — `dstack` does not proceed to updating the next replica until the previous one was fully updated. New and old replicas can coexist and handle requests simultaneously until deployment finishes. | ||
| If approved, `dstack` updates each replica one by one—waiting for each to reach the `running` state before updating the next. |
There was a problem hiding this comment.
I'm still convinced we need to describe the algorithm. From this sentence, it is not clear what "updating" a replica actually means. One may think that dstack just restarts the replica, causing downtime.
waiting for each to reach the
runningstate before updating the next
Not quite — it waits for the old version of the replica to reach the terminated state, and only then proceeds to the next replica.
|
@jvstme Sure, please feel free to merge with your change. |
2 participants
#2180