Open Stack

I think Zane's response pretty much covers it, but here's some comments
since you requested my response:

On Thu, Aug 15, 2013 at 05:50:19PM -0500, Christopher Armstrong wrote:
> *Introduction and Requirements*
> 
> So there's kind of a perfect storm happening around autoscaling in Heat
> right now. It's making it really hard to figure out how I should compose
> this email. There are a lot of different requirements, a lot of different
> cool ideas, and a lot of projects that want to take advantage of
> autoscaling in one way or another: Trove, OpenShift, TripleO, just to name
> a few...
> 
> I'll try to list the requirements from various people/projects that may be
> relevant to autoscaling or scaling in general.
> 
> 1. Some users want a service like Amazon's Auto Scaling or Rackspace's
> Otter -- a simple API that doesn't really involve orchestration.
> 2. If such a API exists, it makes sense for Heat to take advantage of its
> functionality instead of reimplementing it.
> 3. If Heat integrates with that separate API, however, that API will need
> two ways to do its work:
>    1. native instance-launching functionality, for the "simple" use
>    2. a way to talk back to Heat to perform orchestration-aware scaling
> operations.
> 4. There may be things that are different than AWS::EC2::Instance that we
> would want to scale (I have personally been playing around with the concept
> of a ResourceGroup, which would maintain a nested stack of resources based
> on an arbitrary template snippet).
> 5. Some people would like to be able to perform manual operations on an
> instance group -- such as Clint Byrum's recent example of "remove instance
> 4 from resource group A".
> 
> Please chime in with your additional requirements if you have any! Trove
> and TripleO people, I'm looking at you :-)
> 
> 
> *TL;DR*
> 
> Point 3.2. above is the main point of this email: exactly how should the
> autoscaling API talk back to Heat to tell it to add more instances? I
> included the other points so that we keep them in mind while considering a
> solution.
> 
> *Possible Solutions*
> 
> I have heard at least three possibilities so far:
> 
> 1. the autoscaling API should maintain a full template of all the nodes in
> the autoscaled nested stack, manipulate it locally when it wants to add or
> remove instances, and post an update-stack to the nested-stack associated
> with the InstanceGroup.
> 
> Pros: It doesn't require any changes to Heat.
> 
> Cons: It puts a lot of burden of state management on the autoscale API, and
> it arguably spreads out the responsibility of "orchestration" to the
> autoscale API. Also arguable is that automated agents outside of Heat
> shouldn't be managing an "internal" template, which are typically developed
> by devops people and kept in version control.

I think this is definitely the way to go - essentially the definition of
the nested stack template now used inside InstanceGroup moves the the
AutoScaling API, and InstanceGroup gets reimplemented in terms of calls to
the AutoScaling API/service.

As Zane illustrated, this allows a clean layered architecture, and
minimises duplication of functionality/code.

I don't think it's any problem that the AS API internally defines a
template, we're just moving the (mechanical) definition of that template
from one place to another, which it seems it the entire aim of this work
(ie decoupling the AutoScaling/InstanceGroup implementation from the
heat-engine)

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

As above, I think this is backwards, the AutoScaling API will be a layer
below the InstanceGroup resource, it should definitely not be implemented
using it, or modify the nested stack as you mention above.

Re the comments over RPC/ReST interface - it seems to me, if we're going to
all the effort to decouple this, that the AS API should ideally talk to
Heat via the public ReST inteface.

Steve