On 12/10/2012 09:30 AM, Dwight Engen wrote: > On Fri, 07 Dec 2012 12:47:59 -0500 > Stéphane Graber <stgra...@ubuntu.com> wrote: > >> On 12/07/2012 12:25 PM, Serge Hallyn wrote: >>> Quoting Stéphane Graber (stgra...@ubuntu.com): >>> ... >>>> - get_version() (not container specific) >>>> - get_lxc_path() (not container specific) >>>> Returns the storage path for the containers. >>>> Defaults to LXCPATH. >>>> - set_lxc_path(path) (not container specific) >>>> >>>> >>>> Looking at my todolist for this cycle, the highest priority ones >>>> for me would be: >>>> 1) get_lxc_path() >>>> 2) set_lxc_path() >>>> 3) get_cgroup_item() >>>> 4) set_cgroup_item() >>> >>> How would set_lxc_path() work? Would all the lxc code be switched >>> to check /etc/default/lxc.conf for the value, and autoconf would >>> only fill in the value in that file? >> >> So I think we should split the implementation in two: >> 1) Stop hardcoding LXCPATH in all the C code, instead make it default >> to LXCPATH and overrideable by the set_lxc_path() call. >> 2) Discuss implementing a system wide, not container specific, lxc >> configuration file to be used by all distros in a format that's easily >> parsable. > > For 2, doesn't f0e592fc do that?
f0e592fc is more of a bare config that's copied over to every new container than a lxc system configuration file. If we were to add the lxcpath to /etc/lxc/lxc.conf, it'd end up being added to every new container's configuration where it'd be rather useless. I think the naming of /etc/lxc/lxc.conf was rather bad and I should have thought of that back then :) Essentially our current /etc/lxc/lxc.conf should really be /etc/lxc/default.conf, clearly identifying that it's the default configuration for new containers. Then we could use /etc/lxc/lxc.conf for configuration specific to the lxc tools. If that makes sense to everyone else, I think it'd still be possible to change that for alpha2. I expect it to be mostly difficult for Ubuntu users as we've had /etc/lxc/lxc.conf for the past few years, but that's nothing we can't magically figure out and transition in package maintainer scripts. >> Implementing 1) will make it easy for individual commands like >> lxc-list to implement an extra argument letting the user override the >> lookup path. It'll also make it much easier to deal with lxc being >> run as a user at some point in the future. >> >> Obviously, once we have that, some people will want to change the >> default lookup location in one place and have all the commands use >> that path. That's where we need 2) so that we can store that kind of >> settings in a way that's not distro-specific and have all the tools >> in all the different languages to parse that file. >> >>> -serge >>> >> >> > -- Stéphane Graber Ubuntu developer http://www.ubuntu.com
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
