On 11/22/2012 08:39 AM, Natanael Copa wrote: > On Wed, 21 Nov 2012 18:04:03 -0500 > Stéphane Graber <stgra...@ubuntu.com> wrote: > >> This rewrite is mostly compatible with the shell version. >> --active and -1 still work and behave as they used to. > > Does this mean that python will be a requirement for lxc in future? I > am currently working on switching things from vserver, partially > because lxc has opened for less required dependencies on the host. > > Currently an Alpine Linux lxc host with base + lxc installed is 6.9MB > excluding kernel. A corresponding vserver host is 11.6MB. > > Python is 37MB. > > Do we really need this bloat? > > -nc
So let me give some background on what we're trying to do here :) The past 6 months Serge and I have been working on liblxc which has now landed in staging for quite some time. The goal for this library is to offer simple and intuitive access to all the LXC functions. We are now in the process of replacing the old code (C and shell alike) to use the liblxc API so we can clear out some old code from the tree. The new code will have a very similar structure and close to no lxc-specific logic in it as everything will be done by the API. As the library itself is in C, you need bindings to use it in scripting languages. I wrote one such binding for python3 which I'm now using in a few scripts (lxc-start-ephemeral and lxc-ls for now, there are a couple more to come over the next few days). Technically, porting to the API at the moment can either be done in C or python. As LXC doesn't use any of the fancy C libraries like glib to make the developer's life easier, the easiest way to code something nowadays is with python. I perfectly realize that this means we'll start depending on python3 (core only, no extra modules) for our tools and I don't really think it'll be a problem for > 90% of our users, most of which will probably like being able to reuse that code in their own script and be able to easily extend our tools. Now for the remaining < 10%, I think it'd be interesting to write a tool in C, that'd be a very thin layer on top of liblxc and which could be used instead of the regular tools on systems were installation size is a concern. I wouldn't expect that tool to do any of the fancy output, filtering or really any advanced feature we have in the new python tools, but it'd let you create/start/stop/list containers. I'm not saying, I'll write this tool, but I'm saying this sounds like a reasonable, maintainable option for the future and we could also use that tool as a test of the C API. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
