Quoting Stéphane Graber (stgra...@ubuntu.com): > So, I've been thinking a bit about what functions we're currently > missing in the API which would make the bindings and scripts much easier. > > So far, I've been thinking of: > - get_cgroup_item(cgroup, key) > - set_cgroup_item(cgroup, key, value)
Remind me - do we want these to affect the container if it is running as well? Or only the in-memory container representation (optionally to be saved to disk on the next c->save_config()? Oh right, in lxccontainer.h there are also commented-out commit_cgroups() and reread_cgroups(). I guess I was thinking that you'd do set_cgroup_item(...) to only change in-memory settings, commit_cgroups() to apply to a running container, and reread_cgroups() to re-load from configuration file? No we don't need reread_cgroups() I don't think. > - attach(namespaces, command) > Attach to the provided list of namespaces and runs the command inside > the container. +1 for all of these. I'd like to finish with syslog_ns before I get to those though. > - clone(container) > Used in a similar way to create() but instead of creating a new > rootfs, copies the one from an existing container. It gets a bit > trickier when we need to support weird storage backends. I'd like far more detailed discussion on the API for that before I consider coding :) > - console(tty) > Similar to what lxc-console does, attach to the given tty number and > let the user exit with ctrl+a-q Not sure how straightforward this is or we want it to be. Do we just want it to usurp the caller's console like lxc-console does? > - 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) Should be trivial. > 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() > > The rest I currently already have by wrapping around the lxc-* tools, > but it'd be nice to stop doing that and having those calls in the API so > we can rebase the tools on the API and make things a bit more consistent. > > -- > Stéphane Graber > Ubuntu developer > http://www.ubuntu.com > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > VERIFY Test and improve your parallel project with help from experts > and peers. http://goparallel.sourceforge.net > _______________________________________________ > Lxc-devel mailing list > Lxc-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-devel ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
