Open Stack

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.