Open Stack

Excerpts from Steven Dake's message of 2014-02-05 07:35:37 -0800:
> On 02/04/2014 06:34 PM, Robert Collins wrote:
> > On 5 February 2014 13:14, Zane Bitter <zbitter at redhat.com> wrote:
> >
> >
> >> That's not a great example, because one DB server depends on the other,
> >> forcing them into updating serially anyway.
> >>
> >> I have to say that even in general, this whole idea about applying update
> >> policies to non-grouped resources doesn't make a whole lot of sense to me.
> >> For non-grouped resources you control the resource definitions individually
> >> - if you don't want them to update at a particular time, you have the option
> >> of just not updating them.
> > Well, I don't particularly like the idea of doing thousands of
> > discrete heat stack-update calls, which would seem to be what you're
> > proposing.
> >
> > On groups: autoscale groups are a problem for secure minded
> > deployments because every server has identical resources (today) and
> > we very much want discrete credentials per server - at least this is
> > my understanding of the reason we're not using scaling groups in
> > TripleO.
> >
> >> Where you _do_ need it is for scaling groups where every server is based on
> >> the same launch config, so you need a way to control the members
> >> individually - by batching up operations (done), adding delays (done) or,
> >> even better, notifications and callbacks.
> >>
> >> So it seems like doing 'rolling' updates for any random subset of resources
> >> is effectively turning Heat into something of a poor-man's workflow service,
> >> and IMHO that is probably a mistake.
> > I mean to reply to the other thread, but here is just as good :) -
> > heat as a way to describe the intended state, and heat takes care of
> > transitions, is a brilliant model. It absolutely implies a bunch of
> > workflows - the AWS update policy is probably the key example.
> >
> > Being able to gracefully, *automatically* work through a transition
> > between two defined states, allowing the nodes in question to take
> > care of their own needs along the way seems like a pretty core
> > function to fit inside Heat itself. Its not at all the same as 'allow
> > users to define abitrary workflows'.
> >
> > -Rob
> Rob,
> 
> I'm not precisely certain what your proposing, but I think we need to 
> take care not to turn the Heat DSL into a full-fledged programming 
> language.  IMO thousands of updates done through heat is a perfect way 
> for a third party service to do such things - eg control workflow.  
> Clearly there is a workflow gap in OpenStack, and possibly that thing 
> doing the thousands of updates should be a workflow service, rather then 
> TripleO, but workflow is out of scope for Heat proper.  Such a workflow 
> service could potentially fit in the Orchestration program alongside 
> Heat and Autoscaling.  It is too bad there isn't a workflow service 
> already because we are getting alot of pressure to make Heat fill this 
> gap.  I personally believe filling this gap with heat would be a mistake 
> and the correct course of action would be for a workflow service to 
> emerge to fill this need (and depend on Heat for orchestration).
> 

I don't think we want to make it more programmable. I think the opposite,
we want to relieve the template author of workflow by hiding the common
case work-flows behind an update pattern.

To provide some substance to that, if we were to make a workflow service
that does this, it would have to understand templating, and it would
have to understand heat's API. By the time we get done implementing
that, it would look a lot like the resource I've suggested, surrounded
by calls to heatclient and a heat template library.

> I believe this may be what Zane is reacting to; I believe the Heat 
> community would like to avoid making the DSL more programmable because 
> then it is harder to use and support.  The parameters,resources,outputs 
> DSL objects are difficult enough for new folks to pick up and its only 3 
> things to understand...

I do agree that keeping this simple to understand from a template author
perspective is extremely important.