[libvirt] traffic control

[Peter V. Saveliev]

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.