[openstack-dev] [Heat] HOT Software orchestration proposal for workflows
Mike Spreitzer
mspreitz at us.ibm.com
Wed Oct 9 17:07:47 UTC 2013
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>
More information about the OpenStack-dev
mailing list