[lxc-devel] Proposal for use of config includes by templates

[Stéphane Graber]

Hey everyone,

So one recuring problem we've had in Ubuntu is that changes to the
distribution's userspace sometimes requires changes to the default LXC
fstab.

So far we've been updating the two Ubuntu templates every time that
happened and told our users to add the new entries to their existing
configuration.

That's sub-optimal since it forces users to update the configuration of
all their existing containers and leads to a fair amount of bug reports
we could have avoided.


After talking this over with Serge a week or so ago, we came up with the
idea that we should ship those common bits outside of the template
generate configuration and instead have the template add a lxc.include
statement including those common bits.

So a minimal configuration for an Ubuntu container would look like:
---
# Template used to create this container: /usr/share/lxc/templates/lxc-ubuntu
# Parameters passed to the template: -r saucy -a amd64
lxc.network.type = veth
lxc.network.hwaddr = MAC
lxc.network.flags = up
lxc.network.link = BRIDGE
lxc.rootfs = PATH
lxc.mount = PATH

lxc.utsname = tpl-saucy-amd64
lxc.arch = amd64

# When using LXC with apparmor, uncomment the next line to run unconfined:
#lxc.aa_profile = unconfined

# To support container nesting on an Ubuntu host, uncomment next two lines:
#lxc.aa_profile = lxc-container-default-with-nesting
#lxc.hook.mount = /usr/share/lxc/hooks/mountcgroups

# Including standard configuration options
lxc.include = /usr/share/lxc/configs/ubuntu-common
---

"ubuntu-common" would then contain:
---
lxc.pivotdir = lxc_putold
lxc.devttydir = lxc
lxc.tty = 4
lxc.pts = 1024

lxc.cap.drop = sys_module mac_admin mac_override sys_time

lxc.cgroup.devices.deny = a
# Allow any mknod (but not using the node)
lxc.cgroup.devices.allow = c *:* m
lxc.cgroup.devices.allow = b *:* m
# /dev/null and zero
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm
# consoles
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
# /dev/{,u}random
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm
# rtc
lxc.cgroup.devices.allow = c 254:0 rm
# fuse
lxc.cgroup.devices.allow = c 10:229 rwm
# tun
lxc.cgroup.devices.allow = c 10:200 rwm
# full
lxc.cgroup.devices.allow = c 1:7 rwm
# hpet
lxc.cgroup.devices.allow = c 10:228 rwm
# kvm
lxc.cgroup.devices.allow = c 10:232 rwm
---


Not represented above but also part of this, the fstab file we currently
generate would disappear by default and be replaced by equivalent
lxc.mount entries in the common-ubuntu file.

That way, if we need to add/remove capabilities, mounts, cgroup config,
... we can simply push it to the common config and all containers will
automatically benefit from it.


I think this scheme would benefit most distributions and we should
probably introduce those in the upstream git branch in a standard way
(<distro>-common and <distro>-version) where <distro>-version (like
ubuntu-12.04) would be used to add per-version settings when required.

Taking Ubuntu as an example where we currently support 10.04, 12.04,
12.10, 13.04 and 13.10, the ubuntu-13.04 file would contain something like:
lxc.include = /usr/share/lxc/configs/ubuntu-common
lxc.include = /usr/share/lxc/configs/ubuntu-10.04
lxc.include = /usr/share/lxc/configs/ubuntu-12.10
lxc.include = /usr/share/lxc/configs/ubuntu-13.04
lxc.include = /usr/share/lxc/configs/ubuntu-13.10

Thereby keeping config duplication to a minimum.



So any thoughts on that? Do the other template maintainers think it's
something that'd be useful for them and that they'd use? Are there
common cases I didn't think in my proposal?

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130921/5a363d28/attachment.pgp>