Re: OSTree and OCI images

[Giuseppe Scrivano <gscrivan redhat com>]

Hi,

Colin Walters <walters verbum org> writes:

> (Email is better for architecture discussions, so moving back here)
>
> On Thu, Nov 17, 2016, at 05:10 AM, Alexander Larsson wrote:
> > Really the only flatpak specific thing is the mapping from flatpak arch
> > strings to golang/oci arch strings.
>
> Hum, maybe we can just have "hook" functions that allow the caller
> to tweak the content.
>
> > Yeah, I've started extracting this. The first part is ostree support
> > for the Docker/OCI layer format (i.e. whiteout handling and file
> > overriding), which has a PR here:
> >
> > https://github.com/ostreedev/ostree/pull/578
>
> So can we hash out on the list here - what are the advantages
> and disadvantages of this "flattening" approach?
>
> The atomic command right now represents each OCI layer
> as an ostree ref.  When we want to deploy a container,
> we compute the filesystem tree at checkout.

I've recently thought it would be nice to flatten the layers into the
commit for the image in atomic as well.  The commit for the image at the
moment contains only the metadata (the important part is the list of the
OCI layers) used to reconstruct the filesystem.

The problems I wanted to solve with this approach are:

- possibility to delete an intermediate layer (voluntarily or by
  mistake) but keep the integrity of an image that can still be checked
  out.

- simplify the mount of the image for introspection (ostree-union-fuse
  will have to deal with only a single layer and no whiteouts):
  https://github.com/ostreedev/ostree/pull/491

as a side effect, it will also be possible to use OSTree to transport
the image as we can refer directly to a single commit.

Regards,
Giuseppe