<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 2, 2014 at 8:15 AM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 28/11/14 02:33, Qiming Teng wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Dear all,<br>
<br>
Auto-Scaling is an important feature supported by Heat and needed by<br>
many users we talked to. There are two flavors of AutoScalingGroup<br>
resources in Heat today: the AWS-based one and the Heat native one. As<br>
more requests coming in, the team has proposed to separate auto-scaling<br>
support into a separate service so that people who are interested in it<br>
can jump onto it. At the same time, Heat engine (especially the resource<br>
type code) will be drastically simplified. The separated AS service<br>
could move forward more rapidly and efficiently.<br>
<br>
This work was proposed a while ago with the following wiki and<br>
blueprints (mostly approved during Havana cycle), but the progress is<br>
slow. A group of developers now volunteer to take over this work and<br>
move it forward.<br>
</blockquote>
<br></span>
Thank you!<div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
wiki: <a href="https://wiki.openstack.org/wiki/Heat/AutoScaling" target="_blank">https://wiki.openstack.org/<u></u>wiki/Heat/AutoScaling</a><br>
BPs:<br>
- <a href="https://blueprints.launchpad.net/heat/+spec/as-lib-db" target="_blank">https://blueprints.launchpad.<u></u>net/heat/+spec/as-lib-db</a><br>
- <a href="https://blueprints.launchpad.net/heat/+spec/as-lib" target="_blank">https://blueprints.launchpad.<u></u>net/heat/+spec/as-lib</a><br>
- <a href="https://blueprints.launchpad.net/heat/+spec/as-engine-db" target="_blank">https://blueprints.launchpad.<u></u>net/heat/+spec/as-engine-db</a><br>
- <a href="https://blueprints.launchpad.net/heat/+spec/as-engine" target="_blank">https://blueprints.launchpad.<u></u>net/heat/+spec/as-engine</a><br>
- <a href="https://blueprints.launchpad.net/heat/+spec/autoscaling-api" target="_blank">https://blueprints.launchpad.<u></u>net/heat/+spec/autoscaling-api</a><br>
- <a href="https://blueprints.launchpad.net/heat/+spec/autoscaling-api-client" target="_blank">https://blueprints.launchpad.<u></u>net/heat/+spec/autoscaling-<u></u>api-client</a><br>
- <a href="https://blueprints.launchpad.net/heat/+spec/as-api-group-resource" target="_blank">https://blueprints.launchpad.<u></u>net/heat/+spec/as-api-group-<u></u>resource</a><br>
- <a href="https://blueprints.launchpad.net/heat/+spec/as-api-policy-resource" target="_blank">https://blueprints.launchpad.<u></u>net/heat/+spec/as-api-policy-<u></u>resource</a><br>
- <a href="https://blueprints.launchpad.net/heat/+spec/as-api-webhook-trigger-resource" target="_blank">https://blueprints.launchpad.<u></u>net/heat/+spec/as-api-webhook-<u></u>trigger-resource</a><br>
- <a href="https://blueprints.launchpad.net/heat/+spec/autoscaling-api-resources" target="_blank">https://blueprints.launchpad.<u></u>net/heat/+spec/autoscaling-<u></u>api-resources</a><br>
<br>
Once this whole thing lands, Heat engine will talk to the AS engine in<br>
terms of ResourceGroup, ScalingPolicy, Webhooks. Heat engine won't care<br>
how auto-scaling is implemented although the AS engine may in turn ask<br>
Heat to create/update stacks for scaling's purpose. In theory, AS<br>
engine can create/destroy resources by directly invoking other OpenStack<br>
services. This new AutoScaling service may eventually have its own DB,<br>
engine, API, api-client. We can definitely aim high while work hard on<br>
real code.<br>
<br>
After reviewing the BPs/Wiki and some communication, we get two options<br>
to push forward this. I'm writing this to solicit ideas and comments<br>
from the community.<br>
<br>
Option A: Top-Down Quick Split<br>
------------------------------<br>
<br>
This means we will follow a roadmap shown below, which is not 100%<br>
accurate yet and very rough:<br>
<br>
1) Get the separated REST service in place and working<br>
2) Switch Heat resources to use the new REST service<br>
<br>
Pros:<br>
- Separate code base means faster review/commit cycle<br>
- Less code churn in Heat<br>
Cons:<br>
- A new service need to be installed/configured/launched<br>
- Need commitments from dedicated, experienced developers from very<br>
beginning<br>
</blockquote>
<br></div></div>
Anything that involves a kind of flag-day switchover like this (maintaining the implementation in two different places) will be very hard to land, and if by some miracle it does will likely cause a lot of user-breaking bugs.<span class=""><br></span></blockquote><div><br></div><div>Well we can use the environment to provide the two options for a cycle (like the cloud watch lite) and the operator can switch when they feel comfortable.<br></div><div>The reason I'd like to keep the door somewhat open to this is the huge burden of work we will put on Qiming and his<br>team for option B (and the load on the core team). As you know this has been thought of before and fizzled out, I don't want that to happen again.<br>If we can make this more manageable for the team doing this, then I think that is a good thing. We could implement the guts of the AS in<br>a library and import it from both places (to prevent duplicate implementations).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Option B: Bottom-Up Slow Growth<br>
------------------------------<u></u>-<br>
<br>
The roadmap is more conservative, with many (yes, many) incremental<br>
patches to migrate things carefully.<br>
<br>
1) Separate some of the autoscaling logic into libraries in Heat<br>
2) Augment heat-engine with new AS RPCs<br>
3) Switch AS related resource types to use the new RPCs<br>
4) Add new REST service that also talks to the same RPC<br>
(create new GIT repo, API endpoint and client lib...)<br>
<br>
Pros:<br>
- Less risk breaking user lands with each revision well tested<br>
- More smooth transition for users in terms of upgrades<br>
<br></blockquote></span></blockquote><div><br></div><div>I think this is only true up until "4)", at that point it's the same pain as option A<br>(the operator needs a new REST endpoint, daemons to run, etc) - so delayed pain.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Cons:<br>
- A lot of churn within Heat code base, which means long review cycles<br>
- Still need commitments from cores to supervise the whole process<br>
</blockquote>
<br></span>
I vote for option B (surprise!), and I will sign up right now to as many nagging emails as you care to send when you need reviews if you will take on this work :)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
There could be option C, D... but the two above are what we came up with<br>
during the discussion.<br></blockquote></span></blockquote><div><br></div><div>I'd suggest a combination between A and B.<br><br><span class="">1) Separate some of the autoscaling logic into libraries in Heat</span><br></div><div>2) Get the separated REST service in place and working (using the above heat library)<br>3) Add an environment option to be able to switch Heat resources to use the new REST service<br></div><div>4) after a cycle remove the internal support within Heat<br><br></div><div>(open to other suggestions tho') - I am not convinced of the usefulness of the RPC step when that can be bypassed. <br></div><div><br></div><div>-Angus<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Another important thing we talked about is about the open discussion on<br>
this. OpenStack Wiki seems a good place to document settled designs but<br>
not for interactive discussions. Probably we should leverage etherpad<br>
and the mailinglist when moving forward. Suggestions on this are also<br>
welcomed.<br>
</blockquote>
<br></span>
+1<br>
<br>
cheers,<br>
Zane.<div class=""><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>