Nomad Canary Deployment: Stateful Volume Compatibility During Rollbacks

Nomad's canary deployment strategy allows for the incremental update of task groups to verify health before a full promotion. When a deployment is failed or a rollback is triggered, Nomad reverts the task configuration and image version to the previous stable state.

A challenge arises when a new job version introduces changes to the disk layout or data structure within a stateful volume mount. While Nomad manages the orchestration of the binary and configuration, it does not natively coordinate the state of the underlying volume during a version reversion.

If a canary deployment modifies a persistent volume in a way that is incompatible with the previous version, a rollback may result in the previous version attempting to read a mutated data structure.

• How does Nomad handle volume mount consistency when rolling back from a version that modified the disk layout?
• Are there documented mechanisms to prevent a rollback if the underlying stateful volume has reached a point of no return?