Repository navigation
Release v2.1.0
Choreography can now apply one-time data changes when a release starts, and it does so without taking the old release down. A rolling upgrade no longer needs the replica set scaled to zero and back up: new pods start while old pods keep serving.
Added
- Startup patching: implement
ICanApplyPatchand the patch is discovered, ordered by version and applied once per store before the silo takes work. - A cluster-wide patch manager grain that is safe in mixed-release clusters. When a newer host asks an older manager, the manager moves to the newer host before patching, and an older host never patches a store a newer host already patched.
- Resilient startup during rollouts: a lost silo, a rejected message or a patch that outlasts the grain response timeout is retried with back-off instead of failing the start, bounded by
PatchingOptions.MaxWait(15 minutes by default) and reported asPatchingDidNotComplete. - Patch storage for in-memory, MongoDB and SQL (SQL Server and PostgreSQL) stores, with the SQL tables created by Choreography's own migrations.
AddCratisChoreographyPatchingandCratisChoreographyOptions.ConfigurePatchingto turn patching on and tune it.- Complete documentation, reorganized by feature area, with a patching section and troubleshooting entries.