[systemd-devel] Appc support in systemd-importd

[Lennart Poettering]

On Wed, 11.03.15 15:24, Iago López Galeiras (iago at endocode.com) wrote:

(added Vincent Batts to CC)

> Hi,
> 
> We're looking into adding appc[1] support in systemd-importd. An
> appc image (ACI) is just a tar with a "rootfs" directory and a json
> "manifest". We would have to implement image discovery and simply
> extract the rootfs. Some questions:

A great!

I remember Vincent Batts was interested in that too. Vincent, do you
have any code already?

> * I see that the dkr implementation ignores the information in the
>   docker manifest (resource restrictions, binary to exec...). Is
>   that by design or just not implemented yet? Should we do the same
>   with appc (*only* extract the rootfs)?

This is not implemented yet. I want to introduce a concept of .nspawn
files that can carry runtime information for containers (comparable to
a dkr manifest), basically a way to encode the various bits one
currently specifies on the command line in configuration files that
can be searched for by name, where one of these files can be
maintained per tree. This requires a bit of design tough to make sure
we can both ship these files along with their trees and allow local
modifications...

Actually implementing these .nspawn files shuld be easy, the
complexity is just in coming up with a good scheme for discovering,
overriding, provisioning them.

And then, as soon as we have them, the idea would be to convert the
docker/ACI manifests in a smart way. 

> * Alban liked the idea of saving the manifest so we can extract the
>   whole ACI and modify nspawn to detect a container is an ACI and
>   set /var/lib/machines/appc-image.aci/rootfs as the container's
>   root. The benefit of keeping the manifest would be knowing which
>   binary to start. Is that acceptable?

This would be quite different from dkr handling though. Currently my
thinking for dkr is after all that everything gets converted at import
time and from that point on is just a raw directory with an associated
native config file for nspawn. Or in other words: nspawn + machined
have no idea what dkr is, only importd has...

I wonder what it would take to make ACI imports work the same
way... If I understand things right ACI tarballs come with only two
directories: "rootfs" plus "manifest". Maybe it would work to place
"rootfs" for a container "foobar" directly as directory in
/var/lib/machines/foobar, and then placing the manifest as
/var/lib/machines/foobar.aci-manifest, with a converted version as
/var/lib/machines/foobar.nspawn or so?

Lennart

-- 
Lennart Poettering, Red Hat