<div dir="ltr"><div>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.<br>
<br></div>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<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 20, 2014 at 1:21 AM, Georgy Okrokvertskhov <span dir="ltr"><<a href="mailto:gokrokvertskhov@mirantis.com" target="_blank">gokrokvertskhov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>Thanks</div><span class="HOEnZb"><font color="#888888"><div>Georgy</div><div><br></div><div><br></div></font></span></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">
On Wed, Mar 19, 2014 at 1:38 PM, Thomas Spatzier <span dir="ltr"><<a href="mailto:thomas.spatzier@de.ibm.com" target="_blank">thomas.spatzier@de.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Zane Bitter's message on 19/03/2014 18:18:34:<br>
<br>
> From: Zane Bitter <<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>><br>
> To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
> Date: 19/03/2014 18:21<br>
<div>> Subject: Re: [openstack-dev] [Murano][Heat] MuranoPL questions?<br>
><br>
</div><div>> On 19/03/14 05:00, Stan Lagun wrote:<br>
> > Steven,<br>
> ><br>
> > Agree with your opinion on HOT expansion. I see that inclusion of<br>
> > imperative workflows and ALM would require major Heat redesign and<br>
> > probably would be impossible without loosing compatibility with<br>
previous<br>
> > HOT syntax. It would blur Heat mission, confuse current users and rise<br>
a<br>
> > lot of questions what should and what should not be in Heat. Thats why<br>
> > we chose to built a system on top of Heat rather then expending HOT.<br>
><br>
> +1, I agree (as we have discussed before) that it would be a mistake to<br>
> shoehorn workflow stuff into Heat. I do think we should implement the<br>
> hooks I mentioned at the start of this thread to allow tighter<br>
> integration between Heat and a workflow engine (i.e. Mistral).<br>
<br>
</div>+1 on not putting workflow stuff into Heat. Rather let's come up with a<br>
nice way of Heat and a workflow service to work together.<br>
That could be done in two ways: (1) let Heat hand off to a workflow service<br>
for certains tasks or (2) let people define workflow tasks that can easily<br>
work on Heat deployed resources. Maybe both make sense, but right now I am<br>
more leaning towards (2).<br>
<div><br>
><br>
> So building a system on top of Heat is good. Building it on top of<br>
> Mistral as well would also be good, and that was part of the feedback<br>
> from the TC.<br>
><br>
> To me, building on top means building on top of the languages (which<br>
> users will have to invest a lot of work in learning) as well, rather<br>
> than having a completely different language and only using the<br>
> underlying implementation(s).<br>
<br>
</div>That all sounds logical to me and would keep things clean, i.e. keep the<br>
HOT language clean by not mixing it with imperative expression, and keep<br>
the Heat engine clean by not blowing it up to act as a workflow engine.<br>
<br>
When I think about the two aspects that are being brought up in this thread<br>
(declarative description of a desired state and workflows) my thinking is<br>
that much (and actually as much as possible) can be done declaratively the<br>
way Heat does it with HOT. Then for bigger lifecycle management there will<br>
be a need for additional workflows on top, because at some point it will be<br>
hard to express management logic declaratively in a topology model.<br>
Those additional flows on-top will have to be aware of the instance created<br>
from a declarative template (i.e. a Heat stack) because it needs to act on<br>
the respective resources to do something in addition.<br>
<br>
So when thinking about a domain specific workflow language, it should be<br>
possible to define tasks (in a template aware manner) like "on resource XYZ<br>
of the template, do something", or "update resource XYZ of the template<br>
with this state", then do this etc. At runtime this would resolve to the<br>
actual resource instances created from the resource templates. Making such<br>
constructs available to the workflow authors would make sense. Having a<br>
workflow service able to execute this via the right underlying APIs would<br>
be the execution part. I think from an instance API perspective, Heat<br>
already brings a lot for this with the stack model, so workflow tasks could<br>
be written to use the stack API to access instance information. Things like<br>
update of resources is also something that is already there.<br>
<br>
BTW, we have a similar concept (or are working on a refinement of it based<br>
on latest discussions) in TOSCA and call it the "plan portability API",<br>
i.e. an API that a declarative engine would expose so that fit-for-purpose<br>
workflow tasks can be defined on-top.<br>
<br>
Regards,<br>
Thomas<br>
<div><div><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><div class="">-- <br><div dir="ltr"><font color="#999999"><span style>Georgy Okrokvertskhov<br>
Architect,<br><span style="font-family:arial;font-size:small">OpenStack Platform Products,</span><br>
Mirantis</span><br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284</font><br></div>
</div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small">Sincerely yours<br>
Stanislav (Stan) Lagun<br>Senior Developer<br>Mirantis</span></span><br><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"" lang="EN-US">35b/3, Vorontsovskaya
St.</span><br>Moscow, Russia<br>Skype: stanlagun<br><a href="http://www.mirantis.com/" target="_blank">www.mirantis.com</a><br><a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a></span></span></div>
</div>