On Tue, Feb 4, 2014 at 7:34 PM, Robert Collins <robe...@robertcollins.net>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 > > Agreed. I have been assuming that the autoscaling service outside of the Heat engine would need to send several pre-calculated template changes in sequence in order to implement rolling updates for resource groups, but I think it would be much much better if Heat could take care of this as a core feature. -- Christopher Armstrong http://twitter.com/radix/ http://github.com/radix/ http://radix.twistedmatrix.com/ http://planet-if.com/
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
