Skip to content

Commit c3e752a

Browse files
authored
Merge pull request #12403 from gbartolini/dev/db-in-place-upgrades
📖 Add the database use case for in-place updates
2 parents 24a4184 + 3783783 commit c3e752a

File tree

1 file changed

+1
-0
lines changed

1 file changed

+1
-0
lines changed

docs/proposals/20240807-in-place-updates.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -106,6 +106,7 @@ Over time several improvement were made to Cluster API immutable rollouts:
106106
Even if the project continues to improve immutable rollouts, most probably there are and there will always be some remaining use cases where it is complex for users to perform immutable rollouts, or where users perceive immutable rollouts to be too disruptive to how they are used to manage machines in their organization:
107107
* More efficient updates (multiple instances) that don't require re-bootstrap. Re-bootstrapping a bare metal machine takes ~10-15 mins on average. Speed matters when you have 100s - 1000s of nodes to upgrade. For a common telco RAN use case, users can have 30000-ish nodes. Depending on the parallelism, that could take days / weeks to upgrade because of the re-bootstrap time.
108108
* Credentials rotation, e.g. rotating authorized keys for SSH.
109+
* Database workloads that use local storage and rely on application-level replication—rather than storage-level replication—can face significant downtime if recloning is required. In such cases, restoring a database may take hours and disrupt business continuity, compared to a simple reboot that takes just minutes (e.g. PostgreSQL clusters managed by CloudNativePG using local persistent volumes with storage classes like OpenEBS or TopoLVM).
109110

110111
With this proposal, Cluster API provides a new extensibility point for users willing to implement their own specific solution for these problems by implementing an Update extension.
111112

0 commit comments

Comments
 (0)