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