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 <[email protected]> wrote on 10/09/2013 12:59:22 PM: > From: Alex Rudenko <[email protected]> > To: OpenStack Development Mailing List <[email protected]>, > 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 >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
