On 11/03/15 16:56 +0100, Lennart Poettering wrote:
On Wed, 11.03.15 16:33, Lennart Poettering (lenn...@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. vb
pgpJaK8ZPHY5k.pgp
Description: PGP signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
