search

operator-framework / operator-registry

Operator Registry runs in a Kubernetes or OpenShift cluster to provide operator catalog data to Operator Lifecycle Manager.
Apache License 2.0
211 stars 247 forks source link

opm render - add support for image redirection via registries.conf file #994

Open jdockter opened 2 years ago

jdockter commented 2 years ago

Today several opm index and opm registry commands allow passing in a --container-tool parameter to leverage podman , docker , or none. 

 -c, --container-tool string   tool to interact with container images (save, build, etc.). One of: [none, docker, podman] (default "none")

Unfortunately opm render does not allow for shelling out to podman thus redirecting a render command in a shift left pipeline build scenario, ie pre-ga image vs production, is not possible.

Request is to add --container-tool parameter to opm render or similar functionality using containerd if shelling out to other tools is not possible.

FYI @joelanford

jdockter commented 2 years ago

FYI @jchunkins @cdjohnson

jdockter commented 2 years ago

@joelanford wondering if you have had a chance to look at this

joelanford commented 2 years ago

TL;DR: I think its totally reasonable to look into extending the built-in registry pull code to understand registries.conf, but I don't think we should be shelling out.

similar functionality using containerd if shelling out to other tools is not possible.

I think this is the direction we want to go. The trouble with shelling out is two-fold:

  1. The UX of shelling out gives the impression that those other tools should just work, but in reality, we can't easily test all of the different possible configurations that folks might have with those external tools, so we end up really only supporting the simplest configurations.
  2. For every tool we claim support for shelling out to, we have to plumb the right flags to the right places, arrange the arguments the right way, etc., where the eventual outcome is that opm becomes a poor shim around the underlying tooling.

So with the new opm CLIs that involve FBCs, we've intentionally left out support for shelling out. For example, instead of an opm index style command that pulls/amends/pushes images in an all-in-one command, that could be replaced with <yourToolOfChoice> pull/create/cp, opm render <localCatalogPath>, opm generate dockerfile, <yourToolOfChoice> build/push.

If dealing with render-ing catalog images, I'd recommend just using your container tool of choice to pull the image and extract its content locally. From there opm render can render both sqlite files and FBC directories. But going even further, I wouldn't build a workflow around pull/update/push. I'd git clone -> amend catalog -> git commit -> git push -> build/push image.

render-ing bundles is likely where we need to beef things up in some way. There's https://github.com/operator-framework/operator-registry/issues/817, which would enable a similar flow as above if we could come up with a UX that addressed the concerns I raised there.

In the meantime, it seems completely reasonable to look into supporting native support for registries.conf, and perhaps more generally it would be interesting to see if we could vendor something close to all of podman pull except with our own custom storage layer that doesn't require a daemon or a specialized storage driver so that opm can be easily portable across operating systems.