Open Stack

On Fri, Aug 16, 2013 at 1:35 PM, Clint Byrum <clint at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130819/5e585fc1/attachment.html>