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 :| _______________________________________________ vdsm-devel mailing list firstname.lastname@example.org https://fedorahosted.org/mailman/listinfo/vdsm-devel