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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
