-
Story
-
Resolution: Done
-
Normal
-
None
-
None
-
None
-
8
-
False
-
None
-
False
-
OCPSTRAT-1389 - On Cluster Layering: Phase 3 (GA)
-
-
-
8
-
MCO Sprint 256, MCO Sprint 257, MCO Sprint 258
-
0
-
0.000
For the custom pod builder, we have a hardcoded dependency upon the Buildah container image (quay.io/buildah/stable:latest). This causes two problems: 1) It breaks the guarantees that OpenShift makes about everything being built and stable together since that image can change at any time. 2) This makes on-cluster builds not work in a disconnected environment since that image cannot be pulled.
It is worth mentioning that we cannot simply delegate to the image that the OpenShift Image Builder uses and use a Buildah binary there. To remedy this, we'll need to decide on and implement an approach as defined below:
Approach #1: Include Buildah in the MCO image
As part of our container build process, we'll need to install Buildah. Overall, this seems pretty straightforward since the package registry we'd be installing from (the default package registry for a given OCP release) has the appropriate package versions for a given OCP release.
This has the downside that the MCO image size will increase as a result.
Approach #2: Use the OS base image
The OS base image technically has Buildah within it albeit embedded inside Podman. By using this base image, we can effectively lifecycle Buildah in lockstep with the OCP release without significant cognitive or process overhead. Basically, we'd have an e2e test that would perform a build using this image and if it passes, we can be reasonably confident that it will continue to work.
However, it is worth mentioning that I encountered significant difficulty while attempting to make this work in an unprivileged pod.
Done When:
- An approach has been decided upon and implemented.