Open enisoc opened 4 years ago
this needs to be done recursively: after releasing changes to the vtk, the vtk will schedule changes on its vts children which then need to be released; then each vts will schedule changes on the tablet Pods that will need to be released. the idea is that the operator handles actually doing the updates, but the process of deciding which things to update in which order and with what concurrency is left to an orthogonal system
Can you mention how deployments and replicasets (and anything else) falls into this?
Do changes ever get queued in rollout.planetscale.com/scheduled
for Services and other objects that are separate from deployments/pods? Or are such changes always applied immediately?
Can you document the usage of rollout.planetscale.com/cascade
as well? As well as the cases where one needs to manually remove rollout.planetscale.com/cascade
or rollout.planetscale.com/released
?
Can you show examples of adding/removing these annotations?
Is VitessClusterUpdateStrategyType
: Immediate
equivalent to immediately applying rollout.planetscale.com/released
/ rollout.planetscale.com/cascade
recursively on everything? Or is there any other difference?
Are there any kinds of alters that don't go through the rolling update process? (e.g. increasing the number of replicas?)
We really need some official docs on update rollout.
This is the issue to track adding rolling updates as a supported strategy in VTop and we should document that - https://github.com/planetscale/vitess-operator/issues/285
We need to put up a doc on how rolling updates work with the operator. In the meantime, here is at least a dump of some discussion from Slack:
The rollout can be managed with annotations as follows: