Workflow for Conductor

Scott Seago sseago at redhat.com
Tue Jul 10 19:27:35 UTC 2012


On 07/10/2012 03: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...
>
> --Hugh
>
I"m not even sure we'd want to add hooks for Conductor to directly run 
these scripts -- why not use the event infrastructure that Jay is 
working on? This workflow component could register as interested in 
'launch' events (including 'launch awaiting approval' events). Then you 
can do whatever you want in this external component, including making 
API calls back to conductor that actally move the deployment from the 
PENDING_APPROVAL state to the PENDING state (triggering launch)

Scott





More information about the aeolus-devel mailing list