Open Stack

Ability to hook up to application deployment is indeed a good thing. And it
can be done both in HOT and MuranoPL. And Mistral is a good candidate to
handle those hooks. But this is not a replacement for MuranoPL but an
addition to it.

The problem with hooks is that you cannot hoot just into arbitrary place in
deployment workflow. And the author of Python code may not expose the exact
hook that you need. Hooks can work for logging purposes or triggering some
additional workflows but are not good for customization of your workflow
from outside. Hooked code may not have access to all engine's internal
state and workflow context and have even less chances to modify it in a
safe manner


On Thu, Mar 20, 2014 at 1:21 AM, Georgy Okrokvertskhov <
gokrokvertskhov at mirantis.com> wrote:

> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Sincerely yours
Stanislav (Stan) Lagun
Senior Developer
Mirantis
35b/3, Vorontsovskaya St.
Moscow, Russia
Skype: stanlagun
www.mirantis.com
slagun at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140320/62b3804c/attachment.html>