Re: OSTree and OCI images

[Colin Walters <walters verbum org>]

On Fri, Nov 18, 2016, at 04:38 AM, Alexander Larsson wrote:

> However, the code you link to above is not about pruning commits, it is
> about pruning branches (which then refer to the above commits). "ostree
> prune" will never remove a branch like that. Of course, when pulling a
> layer we need to know what ostree commit id the layer id maps to, so we
> need the branch to be there, and thus you need some custom branch
> pruning. (Unless we store the oci layer id => ostree commit id some
> other way.)

Right, conceptually there needs to be two levels of prune logic, one for
oci -> ostree, and ostree.  The atomic command's OCI support does
the first part.

This distinction is all mirrored in rpm-ostree BTW, which currently
uses a separate repo in /ostree/repo/extensions/rpmostree/pkgcache,
as well as its own strong refs on the "base" commits.

And that leads to pointing out there has always been custom refs
in the OSTree-for-host case like "ostree/1/0/0" because of the
distinction between deployments and the origin refs.

Anyways what I'm trying to get at here is - what do we see as the
near term scope of this OCI-in-ostree work?  Should we take
most of the core logic for managing the refs -> layers from
the atomic command down into ostree in addition to the importing?