[libvirt] traffic control

[Daniel P. Berrange]

On Fri, May 17, 2013 at 08:04:30PM +0200, Peter V. Saveliev wrote:
> On 05/17/2013 07:06 PM, Daniel P. Berrange wrote:
> 
> <skip />
> > The idea of handing off this to an external python daemon isn't
> > really very appealing to me, because I don't really like libvirt
> > core functionality depending on anything python related.
> >
> > Really libvirt should just talk network directly rather than
> > invoking the 'tc' command, or there could be a low level C
> > library that could be used instead of 'tc'. I don't think we
> > need to hand this off to a daemon at all.
> 
> Does it matter, in what the language is written the external program,
> when it follows some standard API? Having once C implementation, that
> meets the requirements («no python»), one can always replace python
> implementation. Since there can be more appliances for such traffic
> controlling application, than only libvirt, standard API will make it
> possible to reuse it in other solutions — be it python implementation, C
> or even erlang.
> 
> Python was choosen 'cause of one simple reason: it allows to implement
> netlink message encoder/decoder a way much easier than C, and since the
> netlink control message communication doesn't require high throughput,
> python's performance more than enough. Simple structure handling in
> python allows in this case really fast time-to-market features delivery,
> sometimes it makes sense. Beside of that, some high-level virtualization
> solutions uses python anyway, so mostly this application will not even
> create unique package dependencies, using only python stdlib and no
> tricks like ctypes and so on.
> 
> But as I said, the language in this case really doesn't mean so much,
> having standard RPC API. C — ok, maybe someone will implement it in C
> also. The key issue is to have the API standard.

Yes, the choice language *today* does matter, because it impacts on
the minimum install base size possible with libvirt. It also impacts
on operational aspects becasue python is not a low footprint runtime
from a memory POV, and not OOM friendly. As per my previous mail I
also think this kind of higher level interface to netlink should be
a C library rather than an RPC system. 

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|