ostreedev / ostree-rs-ext

Rust library with higher level APIs on top of the core ostree API
Apache License 2.0
80 stars 26 forks source link

containers: support converting existing base images? #11

Open cgwalters opened 3 years ago

cgwalters commented 3 years ago

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 commented 1 year ago

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 https://github.com/ostreedev/ostree-rs-ext/issues/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 commented 1 year ago

I think we want two things:

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 https://github.com/ostreedev/ostree-rs-ext/issues/388 )

jeamland commented 5 months ago

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 commented 5 months ago

@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.