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! Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
