Open Stack

Hi,

I think notification mechanism proposed in Heat will work fine for
integration with external workflows. The approach which uses workflows
outside of Heat engine sounds consistent with our current approach in
Murano.

I am looking into new TOSCA yaml format and I also ask Mirantis management
to consider joining OASIS. The decision is not made yet, but hopefully will
be made on next week. We eager to jump onto TOSCA standard work and
contribute plan related parts.

Thanks
Georgy




On Wed, Mar 19, 2014 at 1:38 PM, Thomas Spatzier <thomas.spatzier at de.ibm.com
> wrote:

> Excerpts from Zane Bitter's message on 19/03/2014 18:18:34:
>
> > From: Zane Bitter <zbitter at redhat.com>
> > To: openstack-dev at lists.openstack.org
> > Date: 19/03/2014 18:21
> > Subject: Re: [openstack-dev] [Murano][Heat] MuranoPL questions?
> >
> > On 19/03/14 05:00, Stan Lagun wrote:
> > > Steven,
> > >
> > > Agree with your opinion on HOT expansion. I see that inclusion of
> > > imperative workflows and ALM would require major Heat redesign and
> > > probably would be impossible without loosing compatibility with
> previous
> > > HOT syntax. It would blur Heat mission, confuse current users and rise
> a
> > > lot of questions what should and what should not be in Heat. Thats why
> > > we chose to built a system on top of Heat rather then expending HOT.
> >
> > +1, I agree (as we have discussed before) that it would be a mistake to
> > shoehorn workflow stuff into Heat. I do think we should implement the
> > hooks I mentioned at the start of this thread to allow tighter
> > integration between Heat and a workflow engine (i.e. Mistral).
>
> +1 on not putting workflow stuff into Heat. Rather let's come up with a
> nice way of Heat and a workflow service to work together.
> That could be done in two ways: (1) let Heat hand off to a workflow service
> for certains tasks or (2) let people define workflow tasks that can easily
> work on Heat deployed resources. Maybe both make sense, but right now I am
> more leaning towards (2).
>
> >
> > So building a system on top of Heat is good. Building it on top of
> > Mistral as well would also be good, and that was part of the feedback
> > from the TC.
> >
> > To me, building on top means building on top of the languages (which
> > users will have to invest a lot of work in learning) as well, rather
> > than having a completely different language and only using the
> > underlying implementation(s).
>
> That all sounds logical to me and would keep things clean, i.e. keep the
> HOT language clean by not mixing it with imperative expression, and keep
> the Heat engine clean by not blowing it up to act as a workflow engine.
>
> When I think about the two aspects that are being brought up in this thread
> (declarative description of a desired state and workflows) my thinking is
> that much (and actually as much as possible) can be done declaratively the
> way Heat does it with HOT. Then for bigger lifecycle management there will
> be a need for additional workflows on top, because at some point it will be
> hard to express management logic declaratively in a topology model.
> Those additional flows on-top will have to be aware of the instance created
> from a declarative template (i.e. a Heat stack) because it needs to act on
> the respective resources to do something in addition.
>
> So when thinking about a domain specific workflow language, it should be
> possible to define tasks (in a template aware manner) like "on resource XYZ
> of the template, do something", or "update resource XYZ of the template
> with this state", then do this etc. At runtime this would resolve to the
> actual resource instances created from the resource templates. Making such
> constructs available to the workflow authors would make sense. Having a
> workflow service able to execute this via the right underlying APIs would
> be the execution part. I think from an instance API perspective, Heat
> already brings a lot for this with the stack model, so workflow tasks could
> be written to use the stack API to access instance information. Things like
> update of resources is also something that is already there.
>
> BTW, we have a similar concept (or are working on a refinement of it based
> on latest discussions) in TOSCA and call it the "plan portability API",
> i.e. an API that a declarative engine would expose so that fit-for-purpose
> workflow tasks can be defined on-top.
>
> Regards,
> Thomas
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140319/843c4d9e/attachment.html>