[Engine-devel] Announcing a proof of concept REST API for VDSM

[Adam Litke]

We had a very useful discussion on IRC regarding these ideas.  Here is that
transcript for those of you who are interested:

<danken> aglitke: I have, thanks to Chris Write
<danken> I know I should chime in, as well as smizrahi I suppose.
<aglitke> yep... Would be good to get some additional perspectives.
<aglitke> QMF is being pushed hard at the moment.
<aglitke> Or an ovirt-engine light (which I am dubious of)
<smizrahi> Well, I'm really for QMF (or anything else that supports messaging.
<smizrahi> We can't scale if we have to be polled for everything
<aglitke> I guess I don't understand the multiple ovirt-engine use case?  When would multple engines control the same node at the same time?
<aliguori> rest can support notifications
<aliguori> there's nothing that says that an HTTP request has to return in any amount of time
<aglitke> If you need a bus in the engine, just write a QMF broker in your code that consumes the rest APi
<aliguori> you can have an event collection, and fetch it using that as a mechanism to receive async events
<aglitke> Then you can fill your engine code with QMF consoles to spread those events around.
<aliguori> it's certainly not pub/sub, but you don't have to do polling
<smizrahi> aliguori: http requests do time out. You actually do want them to time out. Also we want to announce things like "network disappeared" and "machine crashed which shouldn't just have a request waiting for them.
<aliguori> with real web servers over proxies, yes
<danpb> aglitke: sure you could certainly write the QMF agent for the node which talks REST to VDSM
<danpb> you could even argue that would be good because it would keep VDSM de-coupled from the messaging service
<danpb> as long as the QMF agent & VDSM were on the same node most of the performance questions around REST vs QMF would then be irrelevant, because REST usage would never stray outside the local node for the ovirt-engine <-> vdsm comms path
<aliguori> indeed
<smizrahi> well, as the main consumer of the API would never use the REST API. Why is it even good?
<smizrahi> Just have everyone use AMF
<smizrahi> QMF
<danpb> well it depends on what other consumers of VDSM are around
<smizrahi> I don;t think that any consumer looking to scale would rather use the REST API
<danpb> or whether VDSM were intended to be used standarlone outside RHEVM
<danpb> or were expecting to be easily integrated with other mgmt systems
<aglitke> We would like to be able to use vdsm standalone as a basic requirement.
<smizrahi> danpb: I would love to see it used outside ovirt-engine
<aglitke> There are cases where not all ovirt consumers will want all of the pieces.
<smizrahi> The point being, if ovirt-engine found it necessary to use QMF, why shouldn't any other users
<danpb> eg, if some other 3rd party came along and wanted to use VDSM in their app, but already has a comms system/bus that is not AMQP, then integration will liekly be easier via REST
<smizrahi> apart from the obvious simplicity of REST
<smizrahi> danpb: you do have a point there
<danpb> smizrahi: IME  simplicity of use is key to getting adoption - every piece of extra infrastructure you mandate, reduces your pool of consumers
<danpb> a good % of people will simply not even consider VDSM if it mandated QMF, whereas everyone in today's world can trivially use REST
<aglitke> Also, ovirt-engine can modularize their consumption via QMF such that other projects could pick that up if they wanted to use it.
<aglitke> It's all about building blocks in my mind.
<smizrahi> I see how the AMF proxy xould just be on the host
<smizrahi> QMF
<smizrahi> and we'd have a dedicated collectEvents API call
<aglitke> yes.  I also have some ideas on how to make this interface efficient in vdsm
<aglitke> you could create a resource called an event sink or event monitor
<aglitke> this would essentially be a list of events and task ids you want to watch.
<smizrahi> Ho will async operation work. We would like to have all operations be asynchronous
<smizrahi> How
<aglitke> when this is created, it tells vdsm to set up some internal async handlers to cache the status of these tasks/events.
<smizrahi> yea but them shotrt living tasks have a large overhead
<smizrahi> as they are bound by the minimum collect interval
<aglitke> For those, you would just use the standard polling
<aglitke> aliguori suggested having a single. global event / task source that you could connect to.
<aglitke> danpb suggested using keepalive or chunking
<aliguori> smizrahi, so a QMF -> REST bridge wouldn't be a bad thing either IMHO
<smizrahi> We could technically optimize single host scenarios with a polling a pipe hinting you to collet
<aliguori> i don't really care how things are implemented
<aliguori> but QMF is an obscure protocol today
<aglitke> if we did this, the server could send out things as they happen.
<aliguori> REST is becoming the defacto standard management interface
<smizrahi> I would like to get abarons point of view. Too bad he missed this.
<aglitke> I can post it to the mailing list.
<aglitke> Do we have a marginal consensus among those of us participating here?
<aliguori> smizrahi, REST is really a compromise, if it wasn't REST, I'd be advocating CIM ;-)
<aglitke> yuck
<smizrahi> I would still like to get event handling nailed down before we go full throttle on this
<smizrahi> but I would rather it happening on the mailing lists as all the bigshots are not here
<aglitke> Yeah, I'll try to take a stab at summarizing the thoughts here.  Then I will post to the list for comments with a more thorough writeup...
<smizrahi> aglitke: excellent
<aglitke> Summary of potential architecture:
<aglitke> 1. VDSM adopts a REST API as the lowest level API 
<aglitke> 2. we create a QMF broker that consumes the rest API and exposes a bus to the engine
<aglitke> 3. The engine can add any number of QMF consoles to this bus for things like stats, logging, reports, etc.
<aglitke> 4. ISVs may interact with vdsm directly via its REST API
<aglitke> Outstanding issues:
<aglitke> 1. We must flesh out how events will be presented in the REST API (including the mechanism)
<aglitke> ...
<aglitke> aliguori, danpb, smizrahi: Agreed on these high-level points?
<danpb> aglitke: yeah, that's a viable plan to me
<aliguori> ack
<smizrahi> One of the things I worry is problems with putting ovirt-engine specific logic in the QMF brgide
<smizrahi> I would like to stress that the bridge has to be ovirt-engine specific
<smizrahi> or at least to the same messaging API

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center