Hey everyone, First of all, sorry for coming up with that so late in the 1.0 development cycle. I tried to convince myself for a long time that this wasn't necessary but reality is that with unprivileged containers, we need to start thinking about new ways to let our users create containers.
So briefly put, the idea is to introduce a new template called simply enough "download" (I'm open to better name suggestions) which instead of doing our usual magic of building a rootfs locally will instead download a pre-built rootfs and some metadata from a central server. My goal is to make the dependencies of that template minimal enough that it should be able to run on every distribution that ships LXC, ideally, including Android. Now as for the implementation, the plan is to bring up a new server on the linuxcontainers.org domain which will sit at: https://images.linuxcontainers.org The structure of that server will be something like ├── images │ ├── debian │ │ └── wheezy │ │ └── armhf │ │ └── default │ │ └── 2014-01-10_19:35 │ │ ├── meta.tar.gz │ │ ├── meta.tar.gz.asc │ │ ├── rootfs.tar.gz │ │ └── rootfs.tar.gz.asc │ └── ubuntu │ └── 14.04 │ └── amd64 │ └── default │ └── 2014-01-10_19:30 │ ├── meta.tar.gz │ ├── meta.tar.gz.asc │ ├── rootfs.tar.gz │ └── rootfs.tar.gz.asc └── meta └── 1.0 ├── index-system ├── index-system.asc ├── index-user └── index-user.asc So the filesystem structure is fairly logical and user friendly. Now as for the details of the various files. rootfs.tar.gz is a tarball of only the root filesystem of the container with the tarball starting at what will be the root of the container. meta.tar.gz is a tarball containing a bit of metadata which the template script will need, that includes: - config (mandatory; text file containing a minimal set of config options to include in the container's config) - fstab (mandatory; a standard fstab text file) - expiry (mandatory; text file containing the Unix Epoch of the recommended expiry date for the image) - create-message (mandatory; text file which will be displayed to the user post-create) - *.<compat-level> (optional; any of the above may be overriden by appending .<compat-level> to their name which will be used instead of the original if the compat-level matches that of the currently running LXC). The index-* files are standard CSV files with the following syntax: - <distribution>;<version>;<architecture>;<variant>;<current build>;<url> index-system is for system containers, index-user is for unprivileged containers. index-{system|user}.<compat-level> is also supported and overrides the main index if found. All of those files are signed by the server's GPG key which will be stored in-line in the script. The template itself will require the following arguments: - distribution - version - architecture And the following will be optional: - variant [default: default] - server [default: https://images.linuxcontainers.org] - pubkey [default: inline gpg key] - no-validate [default: off] The goal for the template is to only depend on: - POSIX shell - wget - tar - gzip Which should be satisfiable even by busybox. However, the template will require --no-validate if gpg isn't also installed on the system. The initial set of distros to be supported that way will be any distro that can currently be built from an Ubuntu system (as that's what linuxcontainers.org uses) and that uses the new common-config (currently only ubuntu and ubuntu-cloud) setup (as I really don't want massive config files that change all the time to be part of those images). The compat-level stuff mentioned above is there to allow us to change the way the server works without breaking backward compatibility. It also allows us to introduce new templates to the system only for releases of LXC which support them. The initial value will be "1" and I'm going to need a very very good reason for bumping it (which is why I want all those distros to use lxc.include for their config). With all that said, I'll start working on the implementation of this and hope to have the server working with ubuntu and debian images published over the next few days. If any other distro is interested (I very much hope they all will), start by switching to lxc.include for your config, using something similar to what ubuntu is doing, then get in touch with me. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com
signature.asc
Description: Digital signature
_______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel