Open Stack

Excerpts from Steven Hardy's message of 2013-09-11 05:59:02 -0700:
> On Wed, Sep 11, 2013 at 03:51:02AM +0000, Adrian Otto wrote:
> > It would be better if we could explain Autoscale like this:
> > 
> > Heat -> Autoscale -> Nova, etc.
> > -or-
> > User -> Autoscale -> Nova, etc.
> > 
> > This approach allows use cases where (for whatever reason) the end user does not want to use Heat at all, but still wants something simple to be auto-scaled for them. Nobody would be scratching their heads wondering why things are going in circles.
> > 
> > From an implementation perspective, that means the auto-scale service needs at least a simple linear workflow capability in it that may trigger a Heat orchestration if there is a good reason for it. This way, the typical use cases don't have anything resembling circular dependencies. The source of truth for how many members are currently in an Autoscaling group should be the Autoscale service, not in the Heat database. If you want to expose that in list-stack-resources output, then cause Heat to call out to the Autoscale service to fetch that figure as needed. It is irrelevant to orchestration. Code does not need to be duplicated. Both Autoscale and Heat can use the same exact source code files for the code that launches/terminates instances of resources.
> 
> So I take issue with the "circular dependencies" statement, nothing
> proposed so far has anything resembling a circular dependency.
> 
> I think it's better to consider traditional encapsulation, where two
> projects may very well make use of the same class from a library.  Why is
> it less valid to consider code reuse via another interface (ReST service)?
> 
> The point of the arguments to date, AIUI is to ensure orchestration actions
> and management of dependencies don't get duplicated in any AS service which
> is created.
> 

This is the crux of the reason that Heat should be involved. In the
driving analogy, Heat is not some boot perched on a ladder waiting for
autoscaling to drop a bowling ball on it to turn the car. It is more
like power steering. The driver puts an input into the system, and the
power steering does the hard work. If you ever need the full power of
power steering, then designing the system to be able to bypass power
steering sometimes will make it _more_ complex, not less.

Meanwhile, as the problems that need to be solved become more complex,
Heat will be there to simplify the solutions. If it is ever making system
control more complex, that is Heat's failure and we need to make Heat
simpler. What we should get out of the habit of is bypassing Heat and
building new control systems because Heat doesn't yet do what we want
it to do.

To any who would roll their own orchestration rather than let Heat
do it:

If Heat adds an unacceptable amount of latency, please file a bug.

If Heat adds complexity, please file a bug.

If you've already done that.. I owe you a gold star. :)