<div dir="ltr">On Fri, Aug 16, 2013 at 1:35 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Zane Bitter's message of 2013-08-16 09:36:23 -0700:<br>
<div class="im">> On 16/08/13 00:50, Christopher Armstrong wrote:<br>
> > *Introduction and Requirements*<br>
> ><br>
> > So there's kind of a perfect storm happening around autoscaling in Heat<br>
> > right now. It's making it really hard to figure out how I should compose<br>
> > this email. There are a lot of different requirements, a lot of<br>
> > different cool ideas, and a lot of projects that want to take advantage<br>
> > of autoscaling in one way or another: Trove, OpenShift, TripleO, just to<br>
> > name a few...<br>
> ><br>
> > I'll try to list the requirements from various people/projects that may<br>
> > be relevant to autoscaling or scaling in general.<br>
> ><br>
> > 1. Some users want a service like Amazon's Auto Scaling or Rackspace's<br>
> > Otter -- a simple API that doesn't really involve orchestration.<br>
> > 2. If such a API exists, it makes sense for Heat to take advantage of<br>
> > its functionality instead of reimplementing it.<br>
><br>
> +1, obviously. But the other half of the story is that the API is likely<br>
> be implemented using Heat on the back end, amongst other reasons because<br>
> that implementation already exists. (As you know, since you wrote it ;)<br>
><br>
> So, just as we will have an RDS resource in Heat that calls Trove, and<br>
> Trove will use Heat for orchestration:<br>
><br>
>    user => [Heat =>] Trove => Heat => Nova<br>
><br>
> there will be a similar workflow for Autoscaling:<br>
><br>
>    user => [Heat =>] Autoscaling -> Heat => Nova<br>
><br>
<br>
</div>After a lot of consideration and an interesting IRC discussion, I think<br>
the point above makes it clear for me. Autoscaling will have a simpler<br>
implementation by making use of Heat's orchestration capabilities,<br>
but the fact that Heat will also use autoscaling is orthogonal to that.<br>
<br>
That does beg the question of why this belongs in Heat. Originally<br>
we had taken the stance that there must be only one control system,<br>
lest they have a policy-based battle royale. If we only ever let<br>
autoscaled resources be controlled via Heat (via nested stack produced<br>
by autoscaling), then there can be only one.. control service (Heat).<br>
<br>
By enforcing that autoscaling always talks to "the world" via Heat though,<br>
I think that reaffirms for me that autoscaling, while not really the same<br>
project (seems like it could happily live in its own code tree), will<br>
be best served by staying inside the "OpenStack Orchestration" program.<br>
<br>
The question of private RPC or driving it via the API is not all that<br>
interesting to me. I do prefer the SOA method and having things talk via<br>
their respective public APIs as it keeps things loosely coupled and thus<br>
easier to fit into one's brain and debug/change.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>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.<br>
</div><div><br></div><div>Thanks to Zane and Clint for hashing this out with me in a 2-hour IRC design discussion, it was incredibly helpful :-)</div></div><div><br></div>-- <br><div dir="ltr">IRC: radix<div>Christopher Armstrong</div>
<div>Rackspace</div></div>
</div></div>