Open Stack

On Tue, Feb 4, 2014 at 7:34 PM, Robert Collins <robertc at robertcollins.net>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
>
>
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140204/4ef47c9c/attachment.html>