-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(upgrade): fix rebuild validation #314
Conversation
93af180
to
4525463
Compare
e892ba4
to
d82a0f5
Compare
d82a0f5
to
2796258
Compare
Signed-off-by: sinhaashish <[email protected]>
2796258
to
4101a29
Compare
bors merge |
314: chore(upgrade): fix rebuild validation r=sinhaashish a=sinhaashish After the addition of partial rebuild, the rebuild validations has been changed for upgrade. <! Co-authored-by: sinhaashish <[email protected]>
This PR was included in a batch that successfully built, but then failed to merge into develop. It will not be retried. Additional information: Response status code: 422
{"message":"All comments must be resolved.","documentation_url":"https://docs.github.com/articles/about-protected-branches"} |
bors merge |
Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
After the addition of partial rebuild, the rebuild validations has been changed for upgrade.
The logic to check if any rebuild is in progress has been changed.
Description
The new rebuild validation is based on the logic below.
If all the volumes are online (across the cluster) then continue with upgrade
In case of volumes which are degraded/faulted check for replica rebuild in progress
There can be scenario where the already checked volume becomes degraded later, so add a vector of unhealthy volumes, and wait till the size of unhealthy volumes.
The rebuild in pre-validation i.e. client side is not modified with the above logic as it just checks for rebuilding . And once the job is created the the rebuild is again verified. So all the above logic reside in Upgrade job
Motivation and Context
The rebuild status would have been incorrect if we just check for
child.rebuild_progress.is_some()
Regression
No
How Has This Been Tested?
Ran the manual upgrade.
Types of changes
Checklist: