templates: Let m-c-d binary on host process encapsulated MC on firstboot #1215
Conversation
During firstboot machine-config-daemon running on host will read /etc/ignition-machine-config-encapsulated.json file available on node, process it and applies MachineConfig provided like kernelArguments
openshift-ci-robot
added
the
size/XS
|
/hold |
openshift-ci-robot
added
the
do-not-merge/hold
|
/retest can't wait to test this out 👍 |
|
/retest |
|
/skip |
|
/lgtm |
openshift-ci-robot
added
lgtm
|
I'm about to drop the hold once I run a 4.1->4.2 upgrade |
|
/hold cancel |
openshift-ci-robot
removed
the
do-not-merge/hold
yuqi-zhang
left a comment
yuqi-zhang
left a comment
There was a problem hiding this comment.
/lgtm
Tested with manual payload on latest installer, the kargs is correctly applied and only 1 reboot is incurred due to pivot. Great work!
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: runcom, sinnykumari, yuqi-zhang 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 |
|
@sinnykumari: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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 Please review the full test history for this PR and help us cut down flakes. |
|
Yay! Thank you all for testing and getting it merged. |
|
I think this may have broken upgrade + scaleup from all "born 4.2" clusters (i.e. 4.2 bootimages) to 4.4, because 4.2 doesn't have It won't affect 4.1 bootimages because that has What I mean by "upgrade + scaleup" is that the "born 4.2" cluster is upgraded to 4.4 while retaining 4.2 bootimages, and from there all further worker boots will break. |
|
OK sketching out an outline for a fix:
One should be able to reproduce this problem btw by creating a new machineset even in a "born 4.4" cluster that manually points to the 4.2 bootimages. Which...is something we should probably change our CI to do right now for at least one cloud; for each of {4.1, 4.2, 4.3, ...} test having a worker with that bootimage version join the cluster. |
|
We might also be able to inspect the |
It's super useful to see the bootimage version for debugging things like https://bugzilla.redhat.com/show_bug.cgi?id=1829642 AKA openshift#1215 (comment)
with the user-agent, it would become just a matter of serving the modified template w/o extra plumbing 🤔 |
|
Oooh, or I bet it would work if we generated two systemd units with conditionals! Going to do a PR to sketch that out. |
This is aiming to fix: https://bugzilla.redhat.com/show_bug.cgi?id=1829642 AKA openshift#1215 (comment) Basically we have our systemd units dynamically differentiate between "4.2" and "4.3 or above" by looking at the aleph version.
This is aiming to fix: https://bugzilla.redhat.com/show_bug.cgi?id=1829642 AKA openshift#1215 (comment) Basically we have our systemd units dynamically differentiate between "4.2" and "4.3 or above" by looking at the aleph version.
It's super useful to see the bootimage version for debugging things like https://bugzilla.redhat.com/show_bug.cgi?id=1829642 AKA openshift#1215 (comment)
8 participants
During firstboot machine-config-daemon running on host will read
/etc/ignition-machine-config-encapsulated.json file available on
node, process it and applies MachineConfig provided like
kernelArguments