On 08/01/2011 04:08 PM, Hugh Brock wrote:
On Mon, Aug 01, 2011 at 03:28:38PM -0400, Jason Guiditta wrote:
> On Fri, 2011-07-29 at 17:38 -0400, Perry Myers wrote:
>>> == Option 1: QMF-HTTP Gateway/Bridge ==
>>>
[snip]
>>
>> What would need to be done to make this generic and small footprint
>> dependency-wise?
>>
>> Also, let's say you run this bridge with an Agent 'Foo' which
exports
>> method bar(). But later you add a new method baz(), would the bridge
>> itself need to be updated to handle the new method or is that done
>> transparently somehow (maybe dynamic translation from QMF to REST by
>> introspection/reading schemas)
>
> This is precisely what I had in mind. The initial version of this, as I
> mentioned, was geared specifically toward the imagefactory qmf agent,
> but the intent was to make it more generic over time. (Since it got
> temporarily removed, that plan was somewhat delayed). However, given
> that qmf provides the schema mechanism, and ruby is very good at
> dynamically building methods based on that type of thing, my hope is to
> be able to make this into a very simple wrapper that can generically
> call to/respond from any qmf agent. I would like to see only an
> agent(s) config and endpoint(s) for return handler needed to start the
> thing up and have it 'just work'. If any custom work is needed, there
> is a handler mechanism in pace, so anyone can just subclass that and add
> the custom behavior. The hardest technical bits, I think, are actually
> the part where we have to handle qmf errors, as they tend to be wrapped
> in so many layers, but I am cautiously optimistic that will be doable as
> well.
>
> On the dependency side, they should be fairly light (and already are).
> If you were installing this via rpm, the biggest thing to decide path
> on, imo, is how to pull in just the console(s) this particular bridge
> needs. This could be done in a metapackage, or just docs saying to
> install x,y and z for this particular scenario. However, this is a
> packaging decision, I think, and should not impact the code directly.
> Basically, this would just be a little sinatra webapp that could be
> proxied/load balanced/whatever with a runtime dep of the needed qmf
> consoles, and a lib to read and write xml, should be the bulk of it.
Sounds like a nice addition to whatever QMF's upstream project is...
Agreed, thanks for the info Jay. The question is, of course, what the
timeline for doing this and does it make sense for us to start
integration between Pacemaker Cloud and Conductor with something simpler
to get things working? Then eventually when this generic QMF/REST
bridge matures, we can integrate that as well.
http://qpid.apache.org
QMF is listed on the front page there :)