The extension system PR broke disconnected installs because `oc` is unaware of ICSP. I'd recommended `oc` because it avoids SELinux issues. We may need to fall back to `podman mount` and try to hack around SELinux - or alternatively scheduling a pod on the node that serves via HTTP would likely work very well.
Is https://github.com/openshift/enhancements/pull/334 another option to avoid _not_ using oc?
(In reply to Colin Walters from comment #0) > The extension system PR broke disconnected installs because `oc` is unaware > of ICSP. I'd recommended `oc` because it avoids SELinux issues. > > We may need to fall back to `podman mount` and try to hack around SELinux - I see https://bugzilla.redhat.com/show_bug.cgi?id=1863335 is resolved and we have podman-1.9.3-2.rhaos4.6.el8.x86_64 and container-selinux-2.135.0-1.module+el8.2.1+6849+893e4f4a.noarch in OCP 4.6 nightlies. @Colin do you think this unblocks rpm-ostree selinux issues to perform rebase and install from mounted container in container context? If not, another option is to revert back existing extensions implementation and fallback to previous implementation where we diverged to use oc image extract https://github.com/openshift/machine-config-operator/pull/1850 and we can do rpm-ostreed.service start/stop dance as mentioned in https://github.com/openshift/machine-config-operator/pull/1850#issuecomment-659472732
*** This bug has been marked as a duplicate of bug 1862979 ***
After having a brainstorming session with Antonio today, we came up with another solution to fix the problem and this involves minimal changes: - We keep the current implementation (i.e keep using oc image extract) of CoreOS extensions support - Until oc fixes gets in to support mirror registry- when `oc image extract` fails, we fallback to copying machine-os-content on nodes using `podman pull osImageURL && podman create osImageURL && podman cp container_ID:/ /run/machine-os-content/os-content-XXXX` The fallback solution is applied only when oc image extract has failed.
Removing UpgradeBlocker from this older bug, to remove it from the suspect queue described in [1]. If you feel like this bug still needs to be a suspect, please add keyword again. [1]: https://github.com/openshift/enhancements/pull/475