hunterlodge
commented
1 week ago Looks the InstanceUpdateStrategy.partition can meet this requirement , to some extent. :)
When performing an update type of OpsRequest, if this field presents in the cluster manifest, only the specified number of pods get rolled. The operator can then resume the update by modifying the value of this field to a greater value until it reaches the value of replicas.
The defect is OpsRequest doesn't support 'cancel/rollback'-like requests currently, which means if the update can't go on for some reason, the operator will be put in an awkward position.
What is the user interaction of your feature The operator should be able to control the progress of an update operation.
Is your feature request related to a problem? Please describe. Yes. we need it any time when we make changes to a database such as reconfiguration, upgrade.
If this is a new feature, please describe the motivation and goals. Databases play a crucial role in any business applications. Therefore any update operation for a database should be taken in a controllabe way, which IMO makes such feature an indispensable part of the Kubeblocks. Only by such feature can we implement operations such as canary update.
Describe the solution you'd like In the KB world, I think it could be some types of OpsRequest. For example, to make an update pausable, there could be a PauseUpdate and a ResumeUpdate OpsRequest available for the operator to control the progress of the update. Please also consider a Rollback OpsRequest.
Describe alternatives you've considered I think this is quite an essential feature.