Workflow for Conductor

Jason Guiditta jguiditt at redhat.com
Wed Jul 11 14:45:00 UTC 2012


On 10/07/12 15:34 -0400, Andy Goldstein wrote:
>On Jul 10, 2012, at 3:27 PM, 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)
>
>I'm not familiar with the event infrastructure (sorry, new to the list/project).  How would an external component receive an event?  I guess you'd need to add something to the model so that Deployments are either instantly launched (no launch awaiting approval event generated) or delayed (event generated).  Or perhaps you always generate the event, and if an instance doesn't need approval, have part of Aeolus auto-submit an approval.
>
>Andy

A starting point for getting an idea of the current and planned design
for the event api can be found on our wiki[1].  Further documentation
can be found on the main page[2]. Currently this is just
a small library distributed with conductor.  It is meant to be
modular, extensible, and to eventually support both a rest api and
different back end datastores (syslog is the current output target).
This is meant to allow other systems to do things with events that are
out of scope for conductor to handle directly (such as potentially
your example of a business rules engine that decides if a user has
permission to launch a given instance at a given time.  If that system
wishes to use amqp ro some other technology to communicate with its
own pieces that is fine, but for conductor, I would prefer we not
stray from our design of a RESTful interface.  We have finally gotten
to a point where all our components are attempting to use the same api
style, I would rather not see that muddied when there is not a real
need that cannot be handled already.

-j

[1]
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Feature_1_0_Syslog_Event_Documentation
[2]
https://www.aeolusproject.org/redmine/projects/aeolus/wiki#Event-Subsystem



More information about the aeolus-devel mailing list