[lxc-devel] API wishlist

Dwight Engen dwight.engen at oracle.com
Mon Dec 10 14:30:20 UTC 2012


On Fri, 07 Dec 2012 12:47:59 -0500
Stéphane Graber <stgraber at ubuntu.com> wrote:

> On 12/07/2012 12:25 PM, Serge Hallyn wrote:
> > Quoting Stéphane Graber (stgraber at 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?

> 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
> > 
> 
> 





More information about the lxc-devel mailing list