Excerpts from Zane Bitter's message on 19/03/2014 18:18:34: > From: Zane Bitter <zbit...@redhat.com> > To: openstack-dev@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
