Workflow for Conductor

Andy Goldstein andy.goldstein at redhat.com
Tue Jul 10 19:43:11 UTC 2012


On Jul 10, 2012, at 3:35 PM, Scott Seago wrote:

> On 07/10/2012 03:29 PM, Hugh O. Brock wrote:
>> On Tue, Jul 10, 2012 at 03:27:35PM -0400, Scott Seago wrote:
>>> 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)
>> Interesting Scott. How far are we for having that kind of
>> state-transition API available?
>> 
>> --Hugh
>> 
> The state transition bit is part of the 'approval workflow' proposal (see RFC: Launch requests blocking on approval (#3402) )
> 
> The idea is we may have two separate privilege levels -- one can launch directly, and another can launch with approval. Possibly yet a third for "approvers" -- but this could be the same as 'can launch directly' -- or we could have an explicit list of approvers apart from permissions. My idea (expressed on the thread) is we don't need any huge new infrastructure to support launch with approval -- just a new state added to the deployment states list, and some users bypass, others don't. Then we need 1) alerting (possibly using jayg's alerts infrastructure) and 2) an approval action (accessible via UI and API). That's pretty much all we need. The 3rd party "workflow" bit discussed here can just hook into this (register as an event consumer, do its thing, and then send API calls to approve). Conductor won't know about it, and won't need it for users that want to do this via the conductor UI.

That sounds good to me.  Regarding alerting, is that currently being discussed/designed or implemented?  Is there any info I can read about how it works?

Thanks,
Andy


More information about the aeolus-devel mailing list