10:22 a.m.
On Wed, Nov 30, 2011 at 09:44:19AM -0600, Anthony Liguori wrote:
On 11/30/2011 09:09 AM, Itamar Heim wrote:
> On 11/30/2011 05:00 PM, Adam Litke wrote:
>>> single node and exposing the exact same REST API and behavior of the
>>> multi-node ovirt engine would be easier to cosnume for someone that
>>> wants to interact with a single node same way they would interact
>>> with ovirt-engine.
>>
>> In principle an ovirt-engine-light sounds great. Especially if we could get
the
>> existing GUIs for free. The main concern I have with this is the gargantuan
>> nature of the ovirt-engine and GUI code bases. You want to reserve as many
>> system resources for the guests but it seems that ovirt-engine will consume at
>> least several GB of RAM and one or more CPU cores. How would you lighten up
>> this JBoss stack without rewriting it in a more efficient language? One use
>> case I am interested in is a single-node ovirt instance to control VMs on my
>> laptop. I can spare several hundred MB of RAM at most for the management
stack.
>>
>
> this is much much lighter and faster with jboss7 (which iirc, takes
> 100MB to start, tomcat takes 80MB for comparison).
When thinking about something like ovirt-node, my concern is that a jboss7 based
ovirt-lite would end up significantly impact the size of the image.
I think ovirt-node tends to be around ~100MB today which includes VDSM. A
simple REST API (as Adam proposes) wouldn't increase this size at all.
Just the openjdk package looks to be around 72MB.
IIUC, one of the goals of VDSM is to be a general purpose reusable node
agent for non-oVirt management engines to consume too. IME, to maximise
the chances of success for broad adoption, simplicity & flexibility are
key. Every piece of extra infrastructure a project mandates will reduce
the scope for where it can be used.
The idea of deploying an ovirt-engine-light just to get a REST based
interface to VDSM just doesn't fit in with the simple & flexible approach
you need to succeed. Instead of just installing a simple python package,
you now need to deploy an entire java app server, and application ontop.
Furthermore users who are python developers will be turned off by the
idea ofhaving to deal with java, while java developers will be turned
off by the idea of relying on this python bit at the bottom of the
stack.
Similarly if VDSM mandated use of AMQP for all its communication, this
would be a turn off for usage from applications which already have a
message bus/transport which is not AMQP based.
So, IMHO, if VDSM wants to be easily consumable by other non-oVirt based
systems, having a native REST API directly implemented in VDSM code is a
critical factor to its success.
I don't think this is mutually exclusive with having AMQP used for comms
between VDSM & ovirt-engine. One possible implementation strategy would
be to have a 'vdsm-qmf' agent running on the node which talks REST to
VDSM and translate it to QMF & vica-verca. Or you could have an optional
plugin for VDSM which enabled AQMP as an alternative to REST.
The key is really to ensure that VDSM retains the ability to be deployed
with minimal mandatory infrastructure burden/reqiurements.
Regards,
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 :|