[libvirt] HTTP-API for libvirt

[Stefan de Konink]

Daniel P. Berrange schreef:
>> It is what I proposed to be in libvirtd (native support for clouds), but 
>> then implemented as a client application for libvirtd, that is a service 
>> provider for avahi. And a webserver plugin for Cherokee that is a client 
>> for avahi. Something as namespace collision prevention is something that 
>> is 'on going'.
> 
> How tied is the webserver plugin to Cherokee - I think you'd get more
> interest if there was the option to plugin to apache, since Cherokee
> isn't very widely used / known by comparison. Having never written 
> plugins for either I don't know if this is possible, but having a
> generic plugin for the application logic and then bridges to apache,
> cherokee & other web servers would be nice.

I wrote it for Cherokee because I like Cherokee and I think Cherokee 
kicks Apache + Lighttpd ass ;) No seriously I wrote it as real C code 
plugin to get integration without dependencies on interpreter languages, 
but I guess anyone would be able to do the same thing in Python, once a 
standard has been set.


>>> I'd be interested in seeing the source to understand better what it
>>> is doing. I'd certainly be fine with adding it to our applications
>>> page on the website & wiki. 
>> http://repo.or.cz/w/handlervirt.git
> 
> I've had a quick look, but not got it up & running due to not having
> cherokee in Fedora. My first thought would be that the URL spec needs
> to be more fine-grained / well-defined.

There must be an RPM floating around, was on the mailinglist lately, but 
since it is external plugin development, it is still a bit 'LFS' like to 
get it running.

> Virtual machine names are only guarenteed to be unique to a single host,
> so with your avahi broadcasts aggregating info from multiple hosts you
> will inevitably get namespace clashes based on name alone.

True, but my intention is to start the host from the webservice too. 
Only if it is not present on the network. Exactly this can be prevented, 
*if* libvirtd would look on the network (aka integrate all this in 
libvirtd).


> I'd provide several parallel URL spaces based on the different naming
> 
>   /vm/{UUID}/
>   /host/{HOSTNAME}/vm/{NAME}
>   /host/{HOSTNAME}/vm/{ID}
> 
> UUID is guarenteed to be unique globally, while the other two are only
> per-host unique. I included the /vm/ prefix under the /host/ so you
> can also expose other bits of per-host  information such as networking,
> capabilities and device info, eg for virtual networks:
> 
>    /vnet/{UUID}/
>    /host/{HOSTNAME}/vnet/{NAME}
> 
> I'd also thing of structuring it so that the default install just gives
> info on a single host, and then have an add-on plugin to enable the
> multi-host aggregration. You could have a /local/  shortcut URI to refer
> to the /host/{HOSTNAME}  of the local machine. This gives admins the 
> flexibility to run a mini web service on each node, or have a central
> service on a 3rd part node.

I need the user as separate thing too, because I want to have different 
users (thus different authentication). I don't really get why you want 
to 'webservice' libvirt per host... but the current implementation will 
work transparently. You can start it on any machine, and it would 
probably be possible to only take 'local' avahi domains.


Stefan