Support providing MachineConfig objects directly

[cgwalters]

Today while one can drop things into manifests, we need something that works to provide configuration even before the cluster is up. Think e.g. static network configuration for bare metal. Another case might be internal CA certs.

The installer should support the ability to provide a directory of MachineConfig objects that end up in the rendered Ignition, even the bootstrap node.

[cgwalters]

(Although of course the internal CA certs would only apply to the host, not the platform containers. On that topic we should teach our containers to do the same thing flatpak does in flatpak/flatpak#677 (comment) )

[wking]

Although of course the internal CA certs would only apply to the host, not the platform containers.

Baby steps ;). And "installer-supplied MachineConfig objects" seems like it should cover the installer side of all of this, no? Once the CAs are on the nodes, exposing them to pods (or not) seems like a non-installer issue.

[cgwalters]

And "installer-supplied MachineConfig objects" seems like it should cover the installer side of all of this, no?

Yeah.

Once the CAs are on the nodes, exposing them to pods (or not) seems like a non-installer issue.

Yeah though, one thing I will say after working on GNOME for many years is that even sophisticated users often don't care about understanding the distinctions between the various platform components/layers that comprise the end experience. They just want to file a bug against "gnome-desktop" (which is just a random helper library and totally unrelated to the actual thing)

[wking]

Yeah though, one thing I will say after working on GNOME for many years is that even sophisticated users often don't care about understanding the distinctions between the various platform components/layers that comprise the end experience.

I'm resigned to having the installer function as a triage unit for general OpenShift issues ;). Seems orthogonal to MachineConfig injection.

[wking]

@cgwalters, trying to distinguish between this an a generic "stuff in additional post-pod manifests" (more on that in #1147) or "push additional manifests after the installer exits zero", we'll need these to get pushed after the MCO CRDs have been pushed but before the compute-node MachineSets have been pushed, right? If we push after the compute-node MachineSets, we risk:

1. Nodes coming up based on the MachineSets alone, with no MachineConfig alterations.
2. MachineConfig objects pushed into the cluster.
3. Some machine-config component notices the MachineConfig objects, and reboots the nodes after applying the changes.

when we want:

1. MachineConfig objects pushed into the cluster.
2. Nodes coming up based on the MachineSets with the MachineConfig alterations.

and no extra reboot (although there may be a reboot for other reasons, e.g. an RHCOS pivot). Is that right? And we have to land these on-disk with the bootstrap and control-plane Ignition configs since the installer creates those before there's a functional MCO. For compute nodes, I'd guess the MCS would handle inserting this information into the configured Ignition config? Otherwise I'm not clear on how we'd pick up MachingConfig evolution over the life of the cluster.

[abhinavdahiya]

An example of how to push machineconfigs at install-time. #1150

[DanyC97]

@wking regarding

i'm resigned to having the installer function as a triage unit for general OpenShift issues

that is what openshift-ansible became over years ;)

[abhinavdahiya]

An example of how to push machineconfigs at install-time. #1150

/close

[openshift-ci-robot]

@abhinavdahiya: Closing this issue.

In response to this:

An example of how to push machineconfigs at install-time. #1150

/close

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.