-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add (and possibly require) ostree container commit
#159
Comments
This issue also relates to ostreedev/ostree#2480 so the CLI can just be |
Below some notes from an out-of-band chat that I forgot to write down earlier:
|
One thing that would likely ease implementation of this significantly is if we structure it as:
And that may be it! |
ostree container finalize
ostree container commit
EDIT: actually what I wrote above is wrong because the ostree C code doesn't know about the tar format or how to write it. We discussed a simpler option to start of just adding (Also, a whole thread here around whether we should allow new toplevel directories outside of Then later we can actually move all the commit logic mentioned above from per-machine (client side) to build time i.e. |
The above landed in #205 But let's leave this issue open to doing
|
Just to check on where this stands, is it correct that derived Dockerfiles should use
as the final |
Even though it doesn't do much right now, let's train people to do this because I would like to require this in the future. See ostreedev/ostree-rs-ext#159
Hi, thanks for the ping here! I think we'd forgotten to follow up on this because it'd stalled a little bit on getting the new functionality shipped out, but that has happened now. So I updated coreos/layering-examples#5 as one example. But yes, please do start adding the command now! Does that make sense? I'll see if we can update documentation in this repository too. I fixed the example |
Thanks! This does make sense. Two questions though:
If we don't mind the separate layer, is there any harm in just running
Should
|
That won't help unless the build is done with Remember, docker/OCI containers are just tarballs with JSON metadata. A layer is just a tarball. So without squashing, we'd end up with a series of layers (tarballs) and then one final one which shuffles things around - and the client has to download all those tarballs - duplicating space. On the client, we still need to handle the non-ostree-committed layers because we can't "know" that the files were changed in a later layer. In other words, having |
Tangentially related to this in lieu of better docs elsewhere: It will not work to invoke e.g. ostree makes a strong guarantee it will not affect user data on upgrades, and |
Also sorry...I missed this comment before, and it's now fixed in #364 along with #367 I think where we are now with However: it seems very likely that we will want to drain some logic that lives in rpm-ostree today for things like generating |
The current layered container code performs "ostree importing" client side - we accept arbitrary layer tarballs that could come from a
Dockerfile
or other container build system.Let's consider adding a command line
ostree container container
that is required to be invokedin the container at the end of a build process. For example in a
Dockerfile
:The last step would effectively do most of the heavy lifting we're already doing client side:
In this, I think the biggest benefit is that we can error out if people try to do things like ship content in
/boot
or/var
at build time. But avoiding doing selinux labeling on the client is a not-small benefit too.Note that in order for this to work, it must be invoked for each layer.
The text was updated successfully, but these errors were encountered: