On Tue, Mar 31, 2009 at 12:49 AM, David Lutterkort <lut...@redhat.com> wrote:
> I've spent some time recently banging my head against the limitations of > REST for oVirt - the assumption that REST makes that everything is a > resource on which you execute a fixed number of actions is really nice > if you are dealing with something that looks like a resource fairly > naturally, but gets very annoying when that assumption is broken (like > VM's which can be started, stopped, shut down etc.) I can relate. With this shiny REST hammer in our toolboxes, we want every problem to look like a nail. But while you *can* drive a screw with a hammer (ever find yourself without a screwdriver at just the wrong time?), it's much easier if you use the right tool for the job. REST is great for resource-oriented programming, but is awkward for activity-oriented programming. This article breaks down the difference pretty well: http://www.ibm.com/developerworks/webservices/library/ws-restvsoap/ A hybrid REST-RPC approach seems most appropriate for your needs. Model the VMs and their attributes as resources, but model the actions you might want to perform on a VM (install, configure, start, stop, suspend, deinstall) as methods (XML-RPC, SOAP, roll your own, etc). > We are in the process of implementing API's for oVirt now based on > QMF[1], a small layer on top of Qpid, an open source message bus; the > programming model of QMF is pretty nice since it abstracts all the > messaging etc. away nicely. From a coding point of view, you are dealing > with objects, call methods on them etc. and QMF/Qpid take care of > distributing changes throughout the messaing infrastructure. I like how using a message bus drives the design toward an asynchronous, event-based model. That feels right to me. I also like the ability to snoop on the channels to see what the various components are doing :) This is particularly easy when using Jabber as the message transport, as in Vertebra. I'm not familiar with QMF, but the XML schema definition seems like it might make upgrades painful: will you have to contemporaneously upgrade all components plugged into the bus whenever the schema changes? A schema-free design (the messaging equivalent of duck typing) might be easier to maintain. > Architecturally, everybody is a client connecting to a central broker, > even the server on which the objects really live; the logical client > gets a view of those objects, calling methods on them causes some method > on the server to be executed etc. We're using that to connect various > virtualized hosts together - each host is the 'server' for the VM's that > are running to it, and a client using the QMF API gets to see a > collection of all the VM's on all hosts, can start/stop etc. them > without the need to connect to individual hosts. Some hypothetical questions for you -- no need to reply since this may already be off-topic: If you send one global start command to the bus, how do you know when all VMs have in fact started? Even if you don't have to send commands to individual hosts, you still need to monitor them individually. What happens when a host is down or otherwise disconnected from the message bus when the command to start/stop/delete/etc all VMs goes out? Unless Qpid guarantees delivery, the VM state on that host may be out of sync with the rest of the cluster when it comes back up. I'm a newbie on the list -- apologies for butting in :) Clay --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
