Open Stack

I favor separation of concerns.  I think (4), at least, has got nothing to 
do with infrastructure orchestration, the primary concern of today's heat 
engine.  I advocate (4), but as separate functionality.

Regards,
Mike

Alex Rudenko <alexei.rudenko at gmail.com> wrote on 10/09/2013 12:59:22 PM:

> From: Alex Rudenko <alexei.rudenko at gmail.com>
> To: OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>, 
> Date: 10/09/2013 01:03 PM
> Subject: Re: [openstack-dev] [Heat] HOT Software orchestration 
> proposal for workflows
> 
> Hi everyone,
> 
> I've read this thread and I'd like to share some thoughts. In my 
> opinion, workflows (which run on VMs) can be integrated with heat 
> templates as follows:
> 1. workflow definitions should be defined separately and processed 
> by stand-alone workflow engines (chef, puppet etc). 
> 2. the HOT resources should reference workflows which they require, 
> specifying a type of workflow and the way to access a workflow 
> definition. The workflow definition might be provided along with HOT.
> 3. Heat should treat the orchestration templates as transactions 
> (i.e. Heat should be able to rollback in two cases: 1) if something 
> goes wrong during processing of an orchestration workflow 2) when a 
> stand-alone workflow engine reports an error during processing of a 
> workflow associated with a resource)
> 4. Heat should expose an API which enables basic communication 
> between running workflows. Additionally, Heat should provide an API 
> to workflows that allows workflows to specify whether they completed
> successfully or not. The reference to these APIs should be passed to
> the workflow engine that is responsible for executing workflows on VMs.
> Pros of each point:
> 1 & 2 - keeps Heat simple and gives a possibility to choose the best
> workflows and engines among available ones.
> 3 - adds some kind of all-or-nothing semantics improving the control
> and awareness of what's going on inside VMs.
> 4 - allows workflow synchronization and communication through Heat 
> API. Provides the error reporting mechanism for workflows. If a 
> workflow does not need this functionality, it can ignore it.
> 
> Cons:
> - Changes to existing workflows making them aware of Heat existence 
> are required.
> 
> These thoughts might show some gaps in my understanding of how Heat 
> works, but I would like to share them anyway.
> 
> Best regards,
> Oleksii Rudenko
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131009/eb98f766/attachment.html>