[lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again

[Serge Hallyn]

Quoting Christian Seiler (christian at iwakd.de):
> Hi Serge,
> 
> >> 1. What about the naming convention? Stick with /lxc/$name or
> >>go with
> >>    /machine/$name.lxc (see prev. email)? Or I could make that
> >>    configurable?
> >
> >$name.lxc or lxc.$name seems good for all cases.  It'll benefit
> >unprivileged users also.  By "/machine/$name.lxc" did you actually
> >mean under the /machine group?  If we add lxc as a prefix or suffix,
> >do you think that suffices for the grouping?
> 
> I was looking at what other people (i.e. libvirt) were doing, see this
> previous mail of mine:
> http://article.gmane.org/gmane.linux.kernel.containers.lxc.devel/3999

Ok, how about we make the system-cgroup-dir configurable in
/etc/lxc/lxc.conf?  So if you have

	lxc.system-cgroup-dir = /machine

then root-created containers will end up in /machine (or, if you're
already nested under /lxc/m1, then /lxc/m1/machine).  If that is
unset or /, then you're placed in root cgroup.  If you're not
root, then you end up under your current cgroup (assuming you
have rights to create them, which you won't for some)

Does that seem reasonable?

> >> 2. Any objections to implementing the mountcgroups hook in C?
> >>    Especially if I want to do the cgroup mount point detection
> >>right
> >>    (and not just assume /sys/fs/cgroup) it is going to be a
> >>huge pain
> >>    to do that in shell, whereas in C I could reuse code.
> >
> >Nope - it'll require a hooks/Makefile.am tweak, is all.  I was
> >using scripts originally to encourage people to hack on them,
> >but I'm not sure people are doing that anyway.  (If we wanted
> >to continue supporting that then we might want to use python)
> 
> I think scripts are generally a good idea for this, but not in every
> use case, such as this one. And since the mountcgroups hook might be
> considered part of 'core' functionality, I also think Python is
> perhaps not the best choice, especially since LXC only supports
> Python 3.2+.
> 
> -- Christian
>