On Wed, 11.03.15 15:24, Iago López Galeiras (i...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
