Open Stack

On Thu, Aug 15, 2013 at 6:39 PM, Randall Burt <randall.burt at rackspace.com>wrote:

>
> On Aug 15, 2013, at 6:20 PM, Angus Salkeld <asalkeld at redhat.com> wrote:
>
> > On 15/08/13 17:50 -0500, Christopher Armstrong wrote:
>
> >> 2. There should be a new custom-built API for doing exactly what the
> >> autoscaling service needs on an InstanceGroup, named something
> unashamedly
> >> specific -- like "instance-group-adjust".
> >>
> >> Pros: It'll do exactly what it needs to do for this use case; very
> little
> >> state management in autoscale API; it lets Heat do all the orchestration
> >> and only give very specific delegation to the external autoscale API.
> >>
> >> Cons: The API grows an additional method for a specific use case.
> >
> > I like this one above:
> > adjust(new_size, victim_list=['i1','i7'])
> >
> > So if you are reducing the new_size we look in the victim_list to
> > choose those first. This should cover Clint's use case as well.
> >
> > -Angus
>
> We could just support victim_list=[1, 7], since these groups are
> collections of identical
> resources. Simple indexing should be sufficient, I would think.
>
> 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.
>
>

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.



> >> 3. the autoscaling API should update the "Size" Property of the
> >> InstanceGroup resource in the stack that it is placed in. This would
> >> require the ability to PATCH a specific piece of a template (an
> operation
> >> isomorphic to update-stack).
>
> 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.
>

Agreed.



-- 
IRC: radix
Christopher Armstrong
Rackspace
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130816/93bfeab7/attachment.html>