Setup os dependent machine config extensions. #266
Conversation
openshift-ci
bot
added
the
needs-ok-to-test
|
Hi @smuda. Thanks for your PR. I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
|
/ok-to-test |
openshift-ci
bot
added
ok-to-test
|
@smuda: The following test 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. |
PR openshift#266 added the possibility to use different names for the extension depending on the CoreOS flavour presumably running on the host : "kata-containers" by default and "sandboxed-containers" for RHCOS. This is based on OS detection using os-release(5) files. In order to make a good guess, this logic should be handed over the os-release files of the host, otherwise arbitrary os-release files from the controller image might be used instead. This is exactly what happens in the case of Red Hat's OpenShift Sandboxed Containers (OSC) : the controller image is based on RHEL8. It legitimately fails the RHCOS detection heuristics and we end up trying to use the "kata-containers" name that doesn't exist in RHCOS. Thus preventing deployment of kata and putting the cluster in a degraded state. Trying to make assumptions on the host OS isn't generally recommanded. It is at best fragile and at worse potentially insecure if it requires to expose host details inside containers. This isn't really a direction that OSC is willing to take. Also, there is no real need for runtime detection in the code : the CoreOS flavour is an invariant that can be passed to the controller process when it starts. Let's go for a more simple and robust solution : make it configurable with an environment variable. This allows easy customization in the manifest files and doesn't raise any security concern. "kata-containers" remains the default so this should not change any existing behavior for FCOS. OSC will adapt its downstream manifests to use the RHCOS-friendly name. Fixes: https://issues.redhat.com/browse/KATA-2079 Signed-off-by: Greg Kurz <groug@kaod.org>
- Description of the problem which is fixed/What is the use case
The machine config operator handles RHCOS and FCOS differently when effectuating machine config extensions.
On RHCOS it uses a hardcoded list which is then translated into the actual packages. In our case,
sandboxed-containersare translated intokata-containersand then rpm-ostree is called.On FCOS it just pipes the extensions directly into rpm-ostree, which means that in the current implementation it tries to install
sandboxed-containerswhich doesn't exist in FCOS yum repo.Fixes #267
- What I did
I added an OS detection mechanism and if it's RHCOS I use
sandboxed-containersas extension, otherwise I usekata-containers.In theory it's unfortunate that it's the OS of the operator that I use for guessing what OS the actual worker node has, but I've never heard of an OCP with FCOS or OKD with RHCOS so I think it's a reasonable assumption.
- How to verify it
- Description for the changelog
Support for choosing the right RPM package on OKD/FCOS.