Open Stack

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