Is your improvement request related to a problem? Please describe.
In horizontal scaling scenario, It may occur some problem that may lead opsRuquest to time out and be aborted. In this time user often desert to retry this opsRequest rather than just only to solve the problem and to check the cluster status or pod status in Process-oriented scenarios. Especially the onlineInstanceToOffline and the offlineInstanceToOnline, these two is idempotent because it actually specifies a certain pod name.
In KB, there is a validation blocking the request when i wanna offline a pod which already being offlineInstance. So i expect a feature that can ignore this validation.
The whole plan is shown below:
there will be a switch in annotation, indicate that the validation should work or not.(strict or ignore)
if an instance is both in offlineInstance2Online and onlineInstance2Offline it should return error
if an instance not exist in whether online or offline instance it should return error
if a pod already offline/online it should be removed when calculate the expect component
the list of offlineInstance2Online and onlineInstance2Offline should be placed to opsRequest progress, whether they already done in previous opsRequest or not
6.if the same pod name exists, only one should work
Is your improvement request related to a problem? Please describe. In horizontal scaling scenario, It may occur some problem that may lead opsRuquest to time out and be aborted. In this time user often desert to retry this opsRequest rather than just only to solve the problem and to check the cluster status or pod status in Process-oriented scenarios. Especially the onlineInstanceToOffline and the offlineInstanceToOnline, these two is idempotent because it actually specifies a certain pod name. In KB, there is a validation blocking the request when i wanna offline a pod which already being offlineInstance. So i expect a feature that can ignore this validation.
The whole plan is shown below: