[openstack-dev] [Heat] How the autoscale API should control scaling in Heat
shardy at redhat.com
Mon Aug 19 17:42:36 UTC 2013
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
> 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 :-)
> 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
> *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
> 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.
More information about the OpenStack-dev