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 <zbit...@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
