[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