== 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)
Or am I completely off base?
Perry