containers: support converting existing base images?

[cgwalters]

There's nothing conceptually stopping us from having tooling that takes
a current container image (e.g. what's in debian:stable) and just makes it "ostree ready". Or even
just dyanamically accepting a container image that has a kernel client side.

This may be in scope at some point in the future.

[cgwalters]

One thing that came up is taking a container built using Dockerfile or equivalent, and having support for "cleaning it up", specifically by doing things like reproducible chunking. If we go this route, it'd also make sense to do the other things like SELinux labeling at that time too. xref #388

I could imagine having something like ostree container commit --from-image=quay.io/user/example:latest --content-mapping map.toml where map.toml is something that specifies a set of file paths mapping to a "chunk" or so.

[cgwalters]

I think we want two things:

• Expose the existing client side tooling for mapping from derived image to ostree commit as a tool, per above; it's basically ostree container image pull and then you have an ostree commit. We could document this, but perhaps one would want to be in control of the ref, so it could be a separate verb
• A container image which can accept another (potentially arbitrary) container image as input, do "ostree stuff" to it, and then push it to another registry

The second tool in particular would be a really useful way to avoid the need to RUN ostree container commit (it's more in the domain of #388 )

[jeamland]

As further musing related to my comment over here, would it be better to create something like ostree container image ingest that functioned similar to ... pull but did things like selinux relabelling and allowed you to specify a ref for the result?

[cgwalters]

@jeamland Yes - it'd be relatively straightforward to create a new command like ostree container image commit which took a container image as input, performed labeling and other cleanup, and output a new container image.

It's basically moving to build time what we do on the client side today in store.rs.

The core tradeoff is that there's another magic step needed before "push to registry" and shipping to client systems, but I suspect that wouldn't be very onerous for many places.