Workflow for Conductor

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


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.

Scott





More information about the aeolus-devel mailing list