<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 7:34 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 5 February 2014 13:14, Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>> wrote:<br>

<br>
<br>
> That's not a great example, because one DB server depends on the other,<br>
> forcing them into updating serially anyway.<br>
><br>
> I have to say that even in general, this whole idea about applying update<br>
> policies to non-grouped resources doesn't make a whole lot of sense to me.<br>
> For non-grouped resources you control the resource definitions individually<br>
> - if you don't want them to update at a particular time, you have the option<br>
> of just not updating them.<br>
<br>
</div>Well, I don't particularly like the idea of doing thousands of<br>
discrete heat stack-update calls, which would seem to be what you're<br>
proposing.<br>
<br>
On groups: autoscale groups are a problem for secure minded<br>
deployments because every server has identical resources (today) and<br>
we very much want discrete credentials per server - at least this is<br>
my understanding of the reason we're not using scaling groups in<br>
TripleO.<br>
<div class="im"><br>
> Where you _do_ need it is for scaling groups where every server is based on<br>
> the same launch config, so you need a way to control the members<br>
> individually - by batching up operations (done), adding delays (done) or,<br>
> even better, notifications and callbacks.<br>
><br>
> So it seems like doing 'rolling' updates for any random subset of resources<br>
> is effectively turning Heat into something of a poor-man's workflow service,<br>
> and IMHO that is probably a mistake.<br>
<br>
</div>I mean to reply to the other thread, but here is just as good :) -<br>
heat as a way to describe the intended state, and heat takes care of<br>
transitions, is a brilliant model. It absolutely implies a bunch of<br>
workflows - the AWS update policy is probably the key example.<br>
<br>
Being able to gracefully, *automatically* work through a transition<br>
between two defined states, allowing the nodes in question to take<br>
care of their own needs along the way seems like a pretty core<br>
function to fit inside Heat itself. Its not at all the same as 'allow<br>
users to define abitrary workflows'.<br>
<br>
-Rob<br>
<div class="im"><br></div></blockquote><div><br></div><div>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.</div>
<div><br></div></div><br clear="all"><div><br></div>-- <br><div dir="ltr">Christopher Armstrong<div><a href="http://twitter.com/radix/" target="_blank">http://twitter.com/radix/</a></div><div><a href="http://github.com/radix/" target="_blank">http://github.com/radix/</a><br>
<a href="http://radix.twistedmatrix.com/" target="_blank">http://radix.twistedmatrix.com/</a><br><a href="http://planet-if.com/" target="_blank">http://planet-if.com/</a><br><br></div></div>
</div></div>