kata installation should not watch the 'worker' MCP state #596
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When the MCO migrates nodes between pools, the target pool enters the Updating state and has nodes gradually added to it as they are updated and rebooted while the source pool is drained by simply setting its machine count to the desired value at once and never leaves the Updated state. Because the "worker" pool is the source pool in kata installation, it follows that nothing can be gained by watching its status. Normally it doesn't hurt either but if "worker" is Updating already for some unrelated reason when kata installation is starting, it throws off the isInstallationInProgress detection and thus the whole installation flow. Signed-off-by: Pavel Mores <[email protected]>
pmores
force-pushed
the
kata-install-should-ignore-worker
branch
from
f1e3476 to
d37eebc
Compare
gkurz
reviewed
Apr 3, 2025
gkurz
reviewed
Apr 3, 2025
gkurz
approved these changes
Apr 3, 2025
There was a problem hiding this comment.
The proposed change looks sane and will prevent the rest of the installation flow to be triggered because of external factors.
The extra simplifications that I suggest can be discussed and addressed by this PR but this isn't a strong requirement, so I'm approving right away.
Thanks @pmores !
Previous commit removed the only reason for the 'isKataMcpUpdating' variable to exist. 'isMcoUpdating's value was previously acquired in two stages and 'isKataMcpUpdating' was a name for one of them. Now there's just a single stage left so we remove the variable. 'isInstallationInProgress' is only used at a single place as well but we keep the variable since it gives an explicit name to the actual meaning of the 'isMcpUpdating()' check which could otherwise seem non-obvious. We just move the variable close to its only place of use. Signed-off-by: Pavel Mores <[email protected]>
|
@pmores: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When the MCO migrates nodes between pools, the target pool enters the Updating state and has nodes gradually added to it as they are updated and rebooted while the source pool is drained by simply setting its machine count to the desired value at once and never leaves the Updated state.
Because the "worker" pool is the source pool in kata installation, it follows that nothing can be gained by watching its status.
Normally it doesn't hurt either but if "worker" is Updating already for some unrelated reason when kata installation is starting, it throws off the isInstallationInProgress detection and thus the whole installation flow.