Excerpts from Georgy Okrokvertskhov's message of 2013-10-09 08:37:36 -0700:
> Hi,
>
> In addition I want to add couple words about flexibility and debugging
> capabilities. I believe it is quite important for HOT template engine to
> control all aspects of deployment process execution including software
> components. Right now I believe Heat lack of control of what is going on
> the VM side. In my opinion, HOT template user should be able to define
> what steps are necessary to deploy complex environment and more important,
> he should be able to provide a hints to the engine how to deal with errors
> during deployment. Centralized orchestration sees the whole picture of the
> environment status while scripts on VM usually have quite limited view.
> Workflows specification can have on_error actions and centralized
> orchestration will be capable to make smart decision on how to handle
> errors during deployment.
>
What you have described above is some of what I'd like to see in HOT.
It is an evolution beyond the limitations of the waitcondition that
keeps things simple. Basically, orchestration providing a hook point
at which a portion of the workflow is deferred to some other tool. The
tool signals back when it is done, or has an error. We have that now,
but now, the errors just halt the process. We definitely need a way to
say something like this:
on_error_code: {default: {rebuild_resources: [ Instance1, Loadbalancer1]}}
The OS::Heat::HARestarter was sort of an attempt at some of this.
I take issue with a tool that wants to control everything. That may be
the easy way out, however I believe that it will lead to a very large,
very complex tool that users will be suspicious of.
For me, I'd like to know where my orchestration ends, and my software
configuration, installation, and state management all begin. The interface
can be such that Heat doesn't have to be omniscient and omnipotent.
It just has to help simplify the task of orchestration and get out of
workflow/config/installation/etc.'s way.
> I think we need to have a design discussion about the architecture of this
> centralized orchestration. From the one side, this orchestration should
> have the whole information about environment state and as Heat has full
> exposure to the environment it sounds reasonable to have such orchestration
> as a part of Heat. At the other side, HOT template should be quite simple
> to be useful, so additional workflows concepts might overload DSL syntax
> and additional independent orchestration level also sounds quite reasonable
> and this is what we have now as a Murano project.
>
It sounds like you have learned a lot on this journey and it would
definitely be valuable to collaborate with you so that we can make sure
Heat accommodates the use cases you have uncovered.
> It will be nice to have some initial live discussion before the summit as
> not all developers will be on summit. What do you think about Google
> hangout session at the end of this week or on the next week?
>
I find that summit sessions are most useful when we are at a point where
there are just a few decision points to get through. If we come with too
much already done, then group-think will take over and less-well-formed
ideas will get squelched. If we come without clearly defined decisions
to make, then we'll bike-shed for the full 40 minutes.
So, given that, I think a brief pre-summit discussion is a good idea to
help us figure out where we may have conflicting views and then we can
come ready to hash those out in a high bandwidth environment.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
