Workflow for Conductor

Andy Goldstein andy.goldstein at redhat.com
Tue Jul 10 19:27:21 UTC 2012


On Jul 10, 2012, at 3:24 PM, Hugh O. Brock wrote:

> On Tue, Jul 10, 2012 at 02:18:46PM -0400, Andy Goldstein wrote:
>> Hi all,
>> 
>> First off, sorry for not replying to the posts from before - I just now joined this mailing list.  I wanted to propose an idea for a way to implement workflow/approvals for launching new instances.  I know there is currently a proposal along these lines (https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Launch_requests_blocking_on_approval).  Looking at that, I see the suggestion is to build all the approval directly into Conductor.  What I'm thinking about instead is sending out a message (e.g. Qpid, HornetQ, ActiveMQ) with the launch request information.  Conductor wouldn't be responsible for managing the workflow other than keeping track of PENDING_APPROVAL deployments.  Instead, the workflow would be managed by an external third-party system.  I suppose Conductor could supply a default/minimal approval UI, but the real power is in making the workflow extensible.  Imagine a large enterprise IT department that hooks up the workflow notifications to a business rules engine for more advanced approval logic.
>> 
>> (As an aside, a similar approach could be used for events such as instance started, instance stopped, etc.  Other external systems could consume these events to provide services like billing/chargebacks that wouldn't necessarily need to be features of Aeolus.)
>> 
>> What do you all think?
> 
> Andy, what if we simply provided a hook or a set of hooks around the
> launch workflow? IOW we give you a way to specify a script to run at a
> particular stage in the workflow, and an API to indicate that the hook
> has passed? You could then put whatever messaging setup in front of
> that that you wanted and Conductor itself wouldn't have to know
> anything about it...

That sounds good to me.  Conductor would still have to know whether to proceed with the launch (no approval necessary) or wait (approval required).  I suppose the hook could use a return code to indicate proceed (0) or wait (nonzero)?  There'd also need to be a way to have an external system submit the approval back to Conductor to go ahead with the launch (including proper authentication/authorization).  I assume that'd be via a REST call.

I think hooks could work for other events too.

Andy


More information about the aeolus-devel mailing list