On Thu, 2011-07-28 at 14:58 -0700, Steven Dake wrote:
On 07/28/2011 09:47 AM, Tomas Sedovic wrote:
> On 07/28/2011 01:02 PM, Steven Dake wrote:
>>
>>
>>> As for other services notifying Conductor, this can be as simple as:
>>>
>>> POST /conductor/instances/3141/events
>>>
>>> So, like, fyi, that thingy over over here has changed.
>>>
>>> Possibly with a timestamp in the request body so that we can log when
>>> the event happened vs. when it was received.
>>>
>>> However, this must be tied into whatever way we implement cross-module
>>> authentication and authorization, otherwise everyone will be able to
>>> create phoney events.
>>>
>>
>> This is one advantage of using QMF for events - authentication is free
>> in this model.
I suspect whatever we choose here, there will at the very
least be some
coordination needed here. Perhaps this should be included in the
authentication/encryption features so we consider all the needs of all
pieces at the same time?
>>
>> Is QMF a nonstarter for aeolus?
>
> Given the nature of Conductor (a Rails webapp), it feels more natural to
> communicate via HTTP APIs whenever possible.
>
Agree with this sentiment for Conductor. However, that in no way means
we cannot use qmf as a notification mechanism. I'll outline 2 basic
scenarios here, but the first (either variation) is what I think is the
better path. Perhaps there is a 3rd option I have not thought of, in
which case, more ideas welcome.
== 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.
== Option 2: Console inside Conductor ==
This would be the same console needed for the previous option, but
running directly in the web app. While theoretically possible, I think
this is not the best path for the following reasons (not counting more I
am not thinking of this second, I am sure):
* As ruby doesn't have real threads, when we played with this idea in
the past, issues were encountered in this scenario, where the console
method would block the web app or vice versa. Perhaps some of this could
be alleviated with a better threading model (like jruby), but that would
add other complications (such as the qmf ruby lib being c, which may not
be usable from the jvm)
* This console would have to either write its updates directly to the db
(which we have been trying to avoid, multiple writers, everything should
go through conductor api), or call the conductor api, in which case we
are doing almost everything the previous suggestion would do.
* If the console were to hang or crash, the entire web app woudl also
need to be restarted.
* It just plain doesnt really fit inside the web app. My feeling is
that we should let the conductor stay a web app and not pollute it with
additional pieces that would be better on their own (yes, this one may
be highly opinionated).