-
Notifications
You must be signed in to change notification settings - Fork 461
update.go: refactor calculatePostConfigChangeAction() #3022
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
update.go: refactor calculatePostConfigChangeAction() #3022
Conversation
mkenigs
commented
Mar 16, 2022
kikisdeliveryservice
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a few questions/comments
Currently, post config change actions are calculated as follows: 1) Reboot if there's a force file 2) Reboot if any MachineConfig fields change except for passwd 3) Calculate an action based on file changes Layered updates will need to calculate post config change actions solely based on files, as they will be diffing two images. 1) and 3) can be consolidated into a single function that is shared between layered and legacy updates. All MachineConfig changes (2) will result in file changes on disk, which will cause a reboot if actions are calculated as normal. This is correct for any change except for changes to passwd, which currently do not require any post config change action. In order to preserve this behavior, add a reboot file exception for ssh keys, which is the only field the MCO supports modifying using passwd.
fa308f3 to
c4a929b
Compare
Add some test cases to check that changes to ssh keys result in postConfigChangeActionNone when appropriate
c4a929b to
657f3d0
Compare
|
some aws IAM issues (across PRs) reported in 4-dev /test e2e-aws-upgrade |
kikisdeliveryservice
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job, Matthew. It's a nice refactor the function flow makes sense to me. And we got to learn about Variant IDs 😆
Thanks, that's nice to hear :) Thanks for the review |
|
this needs another review and lgtm @jkyros @cheesesashimi can you PTAL |
jkyros
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense to me and lets us use calculatePostConfigChangeActionFromFiles for layering without breaking existing.
/lgtm
| // If a machine-config-daemon-force file is present, it means the user wants to | ||
| // move to desired state without additional validation. We will reboot the node in | ||
| // this case regardless of what MachineConfig diff is. | ||
| if _, err := os.Stat(constants.MachineConfigDaemonForceFile); err == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels maybe little weird having the forcefile check inside calculatePostConfigChangeActionFromFiles but its' no worse than what we had. Like, we factored out the other criteria so this function would suppoooosedly be making a decision just on this list of files provided...but then we also sneak out to the host's disk to check for a file (which means this function can't run as a 'hypothetical' against a list of files, it would need access to a host disk).
From a "find the largest unit of code that both layered and non-layered can use" standpoint this is good.
Cool for now, not worth holding this up for that, just something to think about for later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's a good point
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jkyros, kikisdeliveryservice, mkenigs The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
@mkenigs: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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/test-infra repository. I understand the commands that are listed here. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
2 similar comments
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
@kikisdeliveryservice do we want to cherry pick this? |