On Fri, Aug 16, 2013 at 1:35 PM, Clint Byrum <cl...@fewbar.com> wrote:
> Excerpts from Zane Bitter's message of 2013-08-16 09:36:23 -0700: > > On 16/08/13 00:50, 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. > > > > +1, obviously. But the other half of the story is that the API is likely > > be implemented using Heat on the back end, amongst other reasons because > > that implementation already exists. (As you know, since you wrote it ;) > > > > So, just as we will have an RDS resource in Heat that calls Trove, and > > Trove will use Heat for orchestration: > > > > user => [Heat =>] Trove => Heat => Nova > > > > there will be a similar workflow for Autoscaling: > > > > user => [Heat =>] Autoscaling -> Heat => Nova > > > > After a lot of consideration and an interesting IRC discussion, I think > the point above makes it clear for me. Autoscaling will have a simpler > implementation by making use of Heat's orchestration capabilities, > but the fact that Heat will also use autoscaling is orthogonal to that. > > That does beg the question of why this belongs in Heat. Originally > we had taken the stance that there must be only one control system, > lest they have a policy-based battle royale. If we only ever let > autoscaled resources be controlled via Heat (via nested stack produced > by autoscaling), then there can be only one.. control service (Heat). > > By enforcing that autoscaling always talks to "the world" via Heat though, > I think that reaffirms for me that autoscaling, while not really the same > project (seems like it could happily live in its own code tree), will > be best served by staying inside the "OpenStack Orchestration" program. > > The question of private RPC or driving it via the API is not all that > interesting to me. I do prefer the SOA method and having things talk via > their respective public APIs as it keeps things loosely coupled and thus > easier to fit into one's brain and debug/change. > > I agree with using only public APIs. I have managed to fit this model of autoscaling managing a completely independent Heat stack into my brain, and I am willing to take it and run with it. Thanks to Zane and Clint for hashing this out with me in a 2-hour IRC design discussion, it was incredibly helpful :-) -- IRC: radix Christopher Armstrong Rackspace
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev