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...
--H
--
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
==
http://aeolusproject.org ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey