1:28 p.m.
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(a)us.ibm.com>
IBM Linux Technology Center