Re: OSTree and OCI images

[Colin Walters <walters verbum org>]

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

In this model OSTree isn't really involved at the transport
level at all, and we don't support image reassembly (bit for bit),
since Docker/OCI basically make that impossible[1].

I'm trying to understand what you mean by
" However we run into layers as we start importing apps from
   oci images which may have multiple layers that need to be combined."

Can you flesh this out a bit more?  What Docker/OCI app would
be imported into flatpak?  And for this use case, it's OK if
we discard the layering structure?  I.e. we don't have a use
case of wanting to pull just modified layers?


[1] https://github.com/projectatomic/skopeo/issues/11