Unpack job does not honor cluster pull configuration #21
Comments
everettraven
added a commit
to everettraven/catalogd
that referenced
this issue
Apr 21, 2023
when creating an unpack job by using init containers to pull the catalog image , populate a volume with fbc configs, and use the opm image to render the configs from the volume fixes operator-framework#21 Signed-off-by: Bryce Palmer <bpalmer@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When we create the unpack job, we directly run
opm render <catalogImage>in a single container. This means that that container directly pulls and reads the catalog image. If we want to take advantage of cluster image pull configurations, we should refactor this job into two containers. One container is the catalog image, from which we copy the FBCs into a shared empty dir. The other container renders that shared empty dir.Note that this only makes sense in the case that the catalog image is a standard docker or OCI image containing FBC data.
If we're using other container formats or FBC data sources, this strategy would not work.
Longer term, I think this highlights the need for rukpak-esque
spec.sourceunion type in the catalog source API.The text was updated successfully, but these errors were encountered: