[libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

Gildas Le Nadan gildas.ml at gmail.com
Thu Mar 25 13:37:52 UTC 2010


Anthony Liguori wrote:
> On 03/25/2010 03:26 AM, Vincent Hanquez wrote:
>> On 24/03/10 21:40, Anthony Liguori wrote:
>>>> If so, what C clients you expected beyond libvirt?
>>>
>>> Users want a C API.  I don't agree that libvirt is the only C 
>>> interface consumer out there.
>>
>> (I've seen this written too many times ...)
>> How do you know that ? did you do a poll or something where *actual* 
>> users vote/tell ?
>>
>> From my point of view, i wouldn't want to write a high level 
>> management toolstack in C, specially
>> since the API is well defined JSON which is easily available in all 
>> high level language out there.
> 
> There's a whole world of C based management toolstacks (CIM).
> 
> Regards,
> 
> Anthony Liguori

That huge companies have developped over-complicated c-based management 
toolstacks doesn't necessarily mean that this is the best way to do it. 
It just mean that they have enough qualified ressources to do it.

A simple, language-neutral API is always preferable in my opinion, since 
it lowers the prerequisites/entry price, and will allow more people to 
use it, including system engineers.

Ensuring that the new API will be easy to use by new comers will also 
ensure that it will be easy to use by existing stacks including libvirt.

Also I second Avi's opinion in another mail that "all command line 
options [should] have qmp equivalents": it is vital for 
flexibility/manageability to be able to programatically change setups 
after a VM was started.

To quote the automation part of the "James White Manifesto"[1], a 
document that is gaining a lot of traction in the sysadmin/devops community:
"The provided API must have all functionality that the application provides.
The provided API must be tailored to more than one language and platform."

Regards,
Gildas

-- 
[1] You can find a copy of it here: 
http://www.kartar.net/2010/03/james-whites-rules-for-infrastructure/




More information about the libvir-list mailing list