<div dir="ltr">On Thu, Aug 15, 2013 at 6:39 PM, Randall Burt <span dir="ltr"><<a href="mailto:randall.burt@rackspace.com" target="_blank">randall.burt@rackspace.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Aug 15, 2013, at 6:20 PM, Angus Salkeld <<a href="mailto:asalkeld@redhat.com">asalkeld@redhat.com</a>> wrote:<br>
<br>
> On 15/08/13 17:50 -0500, Christopher Armstrong wrote:<br><br>
>> 2. There should be a new custom-built API for doing exactly what the<br>
>> autoscaling service needs on an InstanceGroup, named something unashamedly<br>
>> specific -- like "instance-group-adjust".<br>
>><br>
>> Pros: It'll do exactly what it needs to do for this use case; very little<br>
>> state management in autoscale API; it lets Heat do all the orchestration<br>
>> and only give very specific delegation to the external autoscale API.<br>
>><br>
>> Cons: The API grows an additional method for a specific use case.<br>
><br>
> I like this one above:<br>
> adjust(new_size, victim_list=['i1','i7'])<br>
><br>
> So if you are reducing the new_size we look in the victim_list to<br>
> choose those first. This should cover Clint's use case as well.<br>
><br>
> -Angus<br>
<br>
</div></div>We could just support victim_list=[1, 7], since these groups are collections of identical<br>
resources. Simple indexing should be sufficient, I would think.<br>
<br>
Perhaps separating the stimulus from the actions to take would let us design/build toward different policy implementations. Initially, we could have a HeatScalingPolicy that works with the signals that a scaling group can handle. When/if AS becomes an API outside of Heat, we can implement a fairly simple NovaScalingPolicy that includes the args to pass to nova boot.<br>

<div class="im"><br></div></blockquote><div><br></div><div><br></div><div>I don't agree with using indices. I'd rather use the actual resource IDs. For one, indices can change out from under you. Also, figuring out the index of the instance you want to kill is probably an additional step most of the time you actually care about destroying specific instances.</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">
>> 3. the autoscaling API should update the "Size" Property of the<br>
>> InstanceGroup resource in the stack that it is placed in. This would<br>
>> require the ability to PATCH a specific piece of a template (an operation<br>
>> isomorphic to update-stack).<br>
<br>
</div>I think a PATCH semantic for updates would be generally useful in terms of "quality of life" for API users. Not having to pass the complete state and param values for trivial updates would be quite nice regardless of its implications to AS.<br>
</blockquote><div><br></div><div>Agreed.</div><div><br></div><div><br></div></div><div><br></div>-- <br><div dir="ltr">IRC: radix<div>Christopher Armstrong</div><div>Rackspace</div></div>
</div></div>