[lxc-devel] API wishlist

[Stéphane Graber]

On 11/29/2012 02:42 PM, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgraber at 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.

From what I remember, set_cgroup_item and get_cgroup_item are meant to
directly read and write to the cgroup file system entries without
touching the configuration.

If you want to have them stick, then you're supposed to use
set_config_item() to set the value in the config.

My recollection of commit_cgroups() is that its goal is to read the
config and re-apply the cgroup changes.
reread_cgroups() would do the opposite, read the cgroup values and write
the config from them.


I think those two are considerably more tricky to implement than
set_cgroup_item() and get_cgroup_item() and aren't very high on my
priority list at the moment, so feel free to delay the work on
commit_cgroups and reread_cgroups.

The python API has an append_config_item function that combined with
set_cgroup_item will let me easily make persistent cgroup changes
without requiring commit_groups().

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

Agreed. I meant to put it on the agenda for UDS but forgot. I'll see if
I can spend some time drafting a plan for those and send it to the list.

My idea is roughly to split the storage backends into their own scripts,
vaguely similar to templates. They'd all have to implement some kind of
standard interface providing access to the usual features (create,
destroy, clone, ...) then the C code would just call those in the same
way it does with create().

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

That's essentially how I'm doing it at the moment in the python binding
(by calling lxc-console).

I think it'd be the easiest and best implementation for console().

We may want to do some fancier things later by passing a fd or something
back to the caller, but we can always implement a new get_console()
function if we ever need that.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20121129/1f1ac9d8/attachment.pgp>