Manage user data #2827
Manage user data #2827
Conversation
|
/cc @hardys @cgwalters |
openshift-ci
bot
requested review from
cgwalters,
hardys,
kikisdeliveryservice and
sinnykumari
This makes it easier to reuse parts of the function.
With this we let the installer take care of installing the initial user-data secret and we then take over with our managed secret. if we are upgrading (and thus no installer at play), we just create the new (managed) secret. This is a cherry-pick of the original patch 1f52e48, which was later reverted by 1c65355. Signed-off-by: Antonio Murdaca <runcom@linux.com> Co-authored-by: Zane Bitter <zbitter@redhat.com>
zaneb
force-pushed
the
manage-user-data
branch
from
f66e75b to
129d6e4
Compare
|
/retest-required |
There was a problem hiding this comment.
OK I re-skimmed the previous discussion. I have to admit I can just like barely keep all this in my head and it will surely get context switched out again. But your commit message was great in linking to all of the relevant bits.
So...as far as I understand things, the next required step here would be for the installer to switch over to generating machinesets to point to -user-data-managed if it exists?
Marking approved from my PoV but this also requires an MCO team approval I'd say.
Yeah, I will need to follow up by also unreverting openshift/installer#4228 and openshift/hive#1166. |
Oh man, I hadn't realized hive needed changes for this too. It'd be really nice to somehow have that share code with openshift/installer. And just for completeness, now that https://github.com/openshift/hypershift exists does it need updating too? A quick code search turns up openshift/hypershift@d98c7a7 which seems to have dropped that dependency? |
Me neither, I just found it looking at that installer PR.
As far as I can tell, no. I don't see any reference to [master|worker]-user-data in that repo. |
|
/retest-required |
|
OK, I think it was actually a mistake for the installer change to modify the MachineSets for every platform - to date all of those MachineSets have fixed images that never change, so their user data should never change. The only platform we should switch over the worker image names for is baremetal. The baremetal platform doesn't use MachinePools in Hive, so if we limit the change to that then there is nothing to do in Hive. |
Since openshift/machine-config-operator#2827, the MCO creates managed master and worker ignition stub configs to ensure they always use the latest version of the ignition format. Create new master Machines using the master-user-data-managed Secret, and install the initial user data in this Secret instead of the old master-user-data Secret. This is the part of the installer changes for the enhancement: https://github.com/openshift/enhancements/blob/master/enhancements/machine-config/user-data-secret-managed.md A previous version of this patch (but for both masters and workers) was previously committed as 8d278d2, but later reverted by 3920ae4.
|
/retest |
5 similar comments
|
/retest |
|
/retest |
|
/retest |
|
/retest |
|
/retest |
|
/lgtm So just to clarify - the reason this got reverted is it broke the installer interface that allows users to customize the pointer ignition. As mentioned in the description I subsequently made changes to the installer which ensure customizations to the pointer config are translated to a MachineConfig, so it should be safe to restore this AFAICS. /cc @yuqi-zhang @runcom |
|
It appears to me that the remaining tests here are perma-failing for reasons unrelated to this patch. /assign @sinnykumari |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
Is it worth overriding the e2e-agnostic-upgrade job, which seems to be broken eveywhere for everyone? |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
11 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. |
|
/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. |
|
/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. |
|
/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. |
|
/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. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
@zaneb: The following tests failed, say
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/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. |
Since openshift/machine-config-operator#2827, the MCO creates managed master and worker ignition stub configs to ensure they always use the latest version of the ignition format. While currently we don't have an automated way of recreating master nodes, on the baremetal platform we now ship an up-to-date image as part of the release payload, and it would be expected that any reprovisioning of Machines would use this image. Therefore, on the baremetal platform, create new master Machines using the master-user-data-managed Secret, and install the initial user data in this Secret instead of the old master-user-data Secret. This is the part of the installer changes for the enhancement: https://github.com/openshift/enhancements/blob/master/enhancements/machine-config/user-data-secret-managed.md A previous version of this patch (but for both masters and workers, on all platforms) was previously committed in 8d278d2, but later reverted by 3920ae4.
|
Installer changes for this are in openshift/installer#5473 (specifically, the last two commits), and affect only the baremetal platform. |
Since openshift/machine-config-operator#2827, the MCO creates managed master and worker ignition stub configs to ensure they always use the latest version of the ignition format. While currently we don't have an automated way of recreating master nodes, on the baremetal platform we now ship an up-to-date image as part of the release payload, and it would be expected that any reprovisioning of Machines would use this image. Therefore, on the baremetal platform, create new master Machines using the master-user-data-managed Secret, and install the initial user data in this Secret instead of the old master-user-data Secret. This is the part of the installer changes for the enhancement: https://github.com/openshift/enhancements/blob/master/enhancements/machine-config/user-data-secret-managed.md A previous version of this patch (but for both masters and workers, on all platforms) was previously committed in 8d278d2, but later reverted by 3920ae4.
On the baremetal platform, worker MachineSets on newly-installed clusters will automatically use the latest version of CoreOS to provision, as described in https://github.com/openshift/enhancements/blob/master/enhancements/baremetal/coreos-image-in-release.md To ensure that the MachineConfig Ignition stub always uses a compatible version of the Ignition format, point these MachineSets at the Secret managed by the MCO (worker-user-data-managed), which is created since openshift/machine-config-operator#2827. Since a non-managed version of the Secret is not required on this platform, install the worker-user-data-managed Secret initially rather than the previous worker-user-data Secret. Other platforms will continue to install worker-user-data Secrets, which are preserved as they were at cluster creation time, because they are referenced by MachineSets that have fixed CoreOS images. When these MachineSets are updated to always use the latest CoreOS images, they should also be updated to point to the managed user data. This is the part of the installer changes for the enhancement: https://github.com/openshift/enhancements/blob/master/enhancements/machine-config/user-data-secret-managed.md A previous version of this patch (but for all platforms) was previously committed as 8d278d2, but later reverted by 3920ae4.
https://issues.redhat.com/browse/METAL-74
Related issue: #683
Enhancement: https://github.com/openshift/enhancements/blob/master/enhancements/machine-config/user-data-secret-managed.md#machines-user-data-managed-by-the-mco
This change was previously committed in #1792, but reverted again in #2126. With the installer change openshift/installer#4413 in place, Bug 1881703 is now resolved and it is safe to re-add this code.
This is now required for the enhancement https://github.com/openshift/enhancements/blob/master/enhancements/baremetal/coreos-image-in-release.md#implementation-detailsnotesconstraints