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 
<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 
<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 
<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 
<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 
<smizrahi> or at least to the same messaging API

Adam Litke <a...@us.ibm.com>
IBM Linux Technology Center

vdsm-devel mailing list

Reply via email to