On Fri, 2011-07-29 at 17:38 -0400, Perry Myers wrote:
> == Option 1: QMF-HTTP Gateway/Bridge ==
>
> * One the previous version of the aeolus suite, we had a daemon called
> aeolus-connector. This particular daemon was using the Imagefactory
> console that we wrote, but the concept could easily be extended to any
> console. The basic idea is that there is a dedicated 'gateway' that is
> an http service on one side, and talks to one or more qmf consoles on
> the other. This allows any service to:
> * Send events via qmf and not have to worry about converting those
> events into http requests to be sent to the api of a web app. The http
> request/put/whatever is done by the gateway.
> * Send requests from a web app _to_ a service via a standard http
> request, which is already easily done from the web app. The request is
> processed with a thin wrapper to call the appropriate method on the
> agent via the embedded console.
>
> This effectively allows 2-way communication between any web app and any
> qmf-exposed service, while keeping that gateway configurable to be
> clustered/proxied/whatever-is-needed-by-sysadmin. There are 2
> variations how this could be deployed (and we may not have to even
> decide this right away):
>
> 1. Set up this gateway with conductor (ie, on same box or network).
> This would have a level of http auth (cert, krb, w/e), and a level of
> auth/config needed for qmf (similar auth options). The possible added
> complication here would be configuring the qpid domain so to console is
> able to find an agent and register for events (say, if the agent is on
> some sandboxed network location). Again, this may be a minor config
> issue, as I know you can do all kinds of fancy things with qmf for these
> kinds of scenarios.
>
> 2. Set up the gateway inside the pacemaker cloud (different box/network
> from conductor). All the auth bits should be the same here, but
> different config - conductor would need to be reachable in this case via
> http in some way, so I can envision environments where this might not
> work.
>
> === What would need to be done? ===
> * Bring back and enhance the aeolus-connector web service
> * Write a console for the pacemaker agent
> * Add that console and appropriate endpoints into web service/gateway.
> * Conductor would need to both call this gateway and add api entrypoints
> for events to be posted to.
Looking at this more generically... Jay, there may be uses for this
QMF/REST bridge outside of Conductor if it could be made generic and
lightweight.
For the general matahari systems management use cases, we'll be running
QMF Agents on the guest (or host) with a local qpid broker. But say
that you would just rather access the matahari APIs via REST calls
instead of setting up a QMF console? This QMF/REST bridge could sit
alongside the matahari-broker and matahari-agents to expose their APIs
via REST calls.
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.
Or am I completely off base?
Perry