10:24 a.m.
New thread.
Honnestly I'm still lost trying to understand what you wanted
to do.
I have implemented a webserver plugin that allows (by mDNS) to access
all 'VMs' on the network.
http://xen.bot.nu/virt/ <- demo
I didn't understand the point, I just noted you wanted to put
things
in libvirtd, something about event API while to me i don't see the even side
of the proposal.
Using mDNS, mDNS events can be used on the network to subscribe to
certain VM changes. Reboot/Shutdown/etc.
Now suggesting to convey this as part of Java *bindings* sounds even
more
confusing, how does that relate at all ?
You proposed (new) bindings for Java. I have written new bindings using
the HTTP protocol. I wonder what should be done to get it adapted into
libvirt, or standardize the format (like any other API).
Stefan
11:18 a.m.
On Wed, Jun 25, 2008 at 05:24:06PM +0200, Stefan de Konink wrote:
New thread.
> Honnestly I'm still lost trying to understand what you wanted to do.
I have implemented a webserver plugin that allows (by mDNS) to access
all 'VMs' on the network.
http://xen.bot.nu/virt/ <- demo
>I didn't understand the point, I just noted you wanted to put things
>in libvirtd, something about event API while to me i don't see the even
>side of the proposal.
Using mDNS, mDNS events can be used on the network to subscribe to
certain VM changes. Reboot/Shutdown/etc.
>Now suggesting to convey this as part of Java *bindings* sounds even more
>confusing, how does that relate at all ?
You proposed (new) bindings for Java. I have written new bindings using
the HTTP protocol. I wonder what should be done to get it adapted into
libvirt, or standardize the format (like any other API).
If I'm understanding what you're doing, it is sort of a REST style
web services API. It is also adding in certain higher level API
semantics by using mDNS to aggregate info from multiple hosts ?
As such its kind of straddling the boundary between being a service
vs an application.
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.
I'm wary of proprosing an 'offficial' web application since there are
many people building web applications ontop of libvirt[1] & I don't want
to take sides saying one is better than the other.
Daniel
[1] Enomalism, oVirt and another I can't remember the name of, offhand.
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
11:27 a.m.
Daniel P. Berrange schreef:
If I'm understanding what you're doing, it is sort of a REST
style
web services API.
Why is everyone using this REST buzzword lately? :D
It is also adding in certain higher level API
semantics by using mDNS to aggregate info from multiple hosts ?
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'.
I propose to integrate the libvirtd-client/avahi-service provider
(domumdns in the sourcetree) into libvirtd.
As such its kind of straddling the boundary between being a service
vs an application.
It is. But you could also see it as a 'protocol' that is implemented by
an application. What I want to get formalized how such protocol *should*
look like.
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'm wary of proprosing an 'offficial' web application
since there are
many people building web applications ontop of libvirt[1] & I don't want
to take sides saying one is better than the other.
I don't want you to pick sides, but I want to get the 'protocol'
formalised or at least molded into something that has been done for the
Python API.
Stefan
6:16 a.m.
On Wed, Jun 25, 2008 at 06:27:00PM +0200, Stefan de Konink wrote:
Daniel P. Berrange schreef:
>If I'm understanding what you're doing, it is sort of a REST style
>web services API.
Why is everyone using this REST buzzword lately? :D
Useful to distinguish from other web services APIs like SOAP or
WSDL. REST is nice & crack-free :-)
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'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.
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.
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.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
6:46 a.m.
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
5991
days inactive
5993
days old
4 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Stefan de Konink