MCO-289: OCPBUGS-1324: Teach the MCO to use new format image #3317

We decided baseOSContainerImage was clearer than baseOperatingSystemContainer (and the same for the extensions container) so this renames all of this throughout to match. I'm doing this first before all of the rest of the "new image by default" code so if we have to revert one of those commits, we don't have to worry about the names. This just renames all instances of the BaseOperatingSystem variables througout to BaseOS and favors the more clear "ContainerImage" suffix rather than the less clear "Container", as "Container" typically signifies something that's running.

Now that we have the extensions container, we can apply extensions and switch kernels again. This just re-enables that functionality for the 'new image' path during daemon updates, and removes the "not supported" messages.

Both rpm-ostree rebase and update require access to the pull secrets in order to pull manifests and images. This changes the behavior such that we symlink the kubelet config.json secrets to /run/ostree/auth.json when we initialize our "NodeUpdaterClient" (rather than only in rebase) so any of our rpm-ostree calls can use it.

Until we figure out if/how we want to use the extensions container as a service, we're going to have to extract it to disk to use it. In order for that to happen, the daemon needs to know where to get it, so it needs to be present in machineconfig. This adds the extensions container to the machineconfig type, the crd, and the resourcemerge library.

This passes the extensions container from controller config through to machineconfig.

Since we can't use the extensions container as a service right now due to boostrap/dns/complexity, for now, we're going to extract them to disk like we did the extensions in machine-os-contanet. This pulls and extracts the extensions container to /run and adds it as a yum repo if we are on a new format image and there are extensions present in MachineConfig.

Currently if someone overrides OSImageURL on their master pool, the required pools sync in the operator will fail because it checks to make sure the OSImageURL matches, and when it's overridden it doesn't. (This results in degradation and timeouts). The check was originally put in to fix a bug around proper update completion reporting. This allows the check to be skipped if the user has "taken the wheel" by overriding OSImageURL.

This adds an "image selection function" to the controller helpers and a boolean variable in helpers.go that determines which image it will use by default. The intent is that it is that it be set to false by default here, rendering the "new image format by default" functionality inert, but that a later commit will enable it. This logic can be taken out later once we get rid of machine-os-content.

This just flips our "gating boolean" to true so that the MCO will use the new format image by default.

This excludes all non-base (right now, only extensions) images from image-references if the build is using fcos, because we currently don't ship fcos extensions images, and including them would break the payload. This also removes the baseOSExtensionsContainerImage from the osimagurl configmap so the placeholder value doesn't get passed through. (oc won't rewrite it if it's not in image-references).

…ee is too old xref coreos/rpm-ostree@89f5802 Change the logic for firstboot OS updates to detect if rpm-ostree is too old to natively fetch a container image on its own. If so, we use `ex deploy-from-self` via podman. Introduce a new `/etc/machine-config-daemon-force-once` file that will cause us to skip validation, and hence we should re-reconcile and attempt to apply the OS upgrade again, this time natively via rpm-ostree. This is needed for scaleup of old nodes, as well as temporarily for 4.11 upgrades.

rpm-ostree deploy-from-self does get us to the right image, but the MCO doesn't know that because the OSImageURL/Container Name/Custom Deployment name doesn't get set when it rebases, it just uses the commit hash. This tells the MCO to: - inspect the current image specified by OSImageURL, - grab its commit hash from the labels - compare it to the base commit of what we have on-disk. If they match, we know we are on the correct image, even if we did not get there the usual way.

Not needed anymore.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MCO-289: OCPBUGS-1324: Teach the MCO to use new format image #3317

MCO-289: OCPBUGS-1324: Teach the MCO to use new format image #3317

Commits on Sep 27, 2022