<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 6:14 PM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</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 03/02/14 17:09, Clint Byrum wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Excerpts from Thomas Herve's message of 2014-02-03 12:46:05 -0800:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote>
</blockquote></blockquote></div><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
update behavior. I want this resource to be able to control multiple<br>
groups as if they are one in some cases (Such as a case where a user<br>
has migrated part of an app to a new type of server, but not all.. so<br>
they will want to treat the entire aggregate as one rolling update).<br>
<br>
I'm o-k with overloading it to allow resource references, but I'd like<br>
to hear more people take issue with depends_on before I select that<br>
course.<br>
</blockquote>
<br></div>
Resource references in general, and depends_on in particular, feel like very much the wrong abstraction to me. This is a policy, not a resource.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To answer your question, using it with a server instance allows<br>
rolling updates across non-grouped resources. In the example the<br>
rolling_update_dbs does this.<br>
</blockquote>
<br></div>
That's not a great example, because one DB server depends on the other, forcing them into updating serially anyway.<br>
<br>
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.<br>

<br>
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.<br>

<br>
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.<br>
<br>
What we do need for all resources (not just scaling groups) is a way for the user to say "for this particular resource, notify me when it has updated (but, if possible, before we have taken any destructive actions on it), give me a chance to test it and accept or reject the update". For example, when you resize a server, give the user a chance to confirm or reject the change at the VERIFY_RESIZE step (Trove requires this). Or when you replace a server during an update, give the user a chance to test the new server and either keep it (continue on and delete the old one) or not (roll back). Or when you replace a server in a scaling group, notify the load balancer _or some other thing_ (e.g. OpenShift broker node) that a replacement has been created and wait for it to switch over to the new one before deleting the old one. Or, of course, when you update a server to some new config, give the user a chance to test it out and make sure it works before continuing with the stack update. All of these use cases can, I think, be solved with a single feature.<br>

<br>
The open questions for me are:<br>
1) How do we notify the user that it's time to check on a resource? (Marconi?)<br>
2) How does the user ack/nack? (You're suggesting reusing WaitCondition, and that makes sense to me.)<br>
3) How do we break up the operations so the notification occurs at the right time? (With difficulty, but it should be do-able.)<br>
4) How does the user indicate for which resources they want to be notified? (Inside an update_policy? Another new directive at the type/properties/depends_on/<u></u>update_policy level?)<div class="im"><br></div></blockquote>
<div><br></div><div>To relate this to another interesting feature, I think it would also be super awesome if Heat grew the ability to support remotely-hosted resource *types* (in addition to the resource notifications you're talking about) by way of an API over Marconi (or maybe just a simple REST API that Heat would invoke). I'm pretty sure CFN has something like this, too, using their queue service. And I think their thing has the custom code ACK back over the queue service to indicate that operations are complete, fwiw.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">we have a need for more generic notification system, it would be nice to find common grounds. Maybe we can invert the relationship? Add a "notified_resources" attribute, which would call hooks on the "parent" when actions are happening.<br>

<br>
</blockquote>It also seems that the interface you're creating (child_creating/child_<u></u>updating) is fairly specific to your use case. For autoscaling 
<br>
I'm open to a different interface design. I don't really have a firm<br>
grasp of the generic behavior you'd like to model though. This is quite<br>
concrete and would be entirely hidden from template authors, though not<br>
from resource plugin authors. Attributes sound like something where you<br>
want the template authors to get involved in specifying, but maybe that<br>
was just an overloaded term.<br>
<br>
So perhaps we can replace this interface with the generic one when your<br>
use case is more clear?<br>
</blockquote>
<br></div>
I'm not sure about the implementation Thomas proposed, but I believe the use case he has in mind is the third of the four I listed above (replace a server in a scaling group).<br>
<br></blockquote><div><br></div><div><br></div><div>I think another use case is temporarily removing a server from a load balancer when it's being e.g. resized.</div></div><br clear="all"><div><br></div>-- <br><div dir="ltr">
<div>IRC: radix</div><div><a href="http://twitter.com/radix">http://twitter.com/radix</a></div>Christopher Armstrong<div>Rackspace</div></div>
</div></div>