[systemd-devel] Appc support in systemd-importd
vbatts at redhat.com
Tue Mar 17 10:10:29 PDT 2015
On 11/03/15 16:56 +0100, Lennart Poettering wrote:
>On Wed, 11.03.15 16:33, Lennart Poettering (lennart at poettering.net) wrote:
>> > * 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?
>Thinking about this more:
>Given the ACI requires some HTTP service to be exposed towards the
>container I figure we have to teach ACI support anyway to nspawn. And
>if that's the case we can as well support it all the way in machined
>and nspawn, and support its untarred stuff natively without
>rearranging the directories. I figure Alban's idea is good then!
This intermediary state information for containers, is there a format
you had in mind? I'm thinking it would largely be the pieces that are
needed to plug into a unit file.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 181 bytes
Desc: not available
More information about the systemd-devel