<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 28, 2014 at 5:33 PM, Qiming Teng <span dir="ltr"><<a href="mailto:tengqim@linux.vnet.ibm.com" target="_blank">tengqim@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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><div><br></div><div>Thank you for taking on this big project!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
wiki: <a href="https://wiki.openstack.org/wiki/Heat/AutoScaling" target="_blank">https://wiki.openstack.org/wiki/Heat/AutoScaling</a><br>
BPs:<br>
 - <a href="https://blueprints.launchpad.net/heat/+spec/as-lib-db" target="_blank">https://blueprints.launchpad.net/heat/+spec/as-lib-db</a><br>
 - <a href="https://blueprints.launchpad.net/heat/+spec/as-lib" target="_blank">https://blueprints.launchpad.net/heat/+spec/as-lib</a><br>
 - <a href="https://blueprints.launchpad.net/heat/+spec/as-engine-db" target="_blank">https://blueprints.launchpad.net/heat/+spec/as-engine-db</a><br>
 - <a href="https://blueprints.launchpad.net/heat/+spec/as-engine" target="_blank">https://blueprints.launchpad.net/heat/+spec/as-engine</a><br>
 - <a href="https://blueprints.launchpad.net/heat/+spec/autoscaling-api" target="_blank">https://blueprints.launchpad.net/heat/+spec/autoscaling-api</a><br>
 - <a href="https://blueprints.launchpad.net/heat/+spec/autoscaling-api-client" target="_blank">https://blueprints.launchpad.net/heat/+spec/autoscaling-api-client</a><br>
 - <a href="https://blueprints.launchpad.net/heat/+spec/as-api-group-resource" target="_blank">https://blueprints.launchpad.net/heat/+spec/as-api-group-resource</a><br>
 - <a href="https://blueprints.launchpad.net/heat/+spec/as-api-policy-resource" target="_blank">https://blueprints.launchpad.net/heat/+spec/as-api-policy-resource</a><br>
 - <a href="https://blueprints.launchpad.net/heat/+spec/as-api-webhook-trigger-resource" target="_blank">https://blueprints.launchpad.net/heat/+spec/as-api-webhook-trigger-resource</a><br>
 - <a href="https://blueprints.launchpad.net/heat/+spec/autoscaling-api-resources" target="_blank">https://blueprints.launchpad.net/heat/+spec/autoscaling-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></blockquote><div><br></div><div>Yes, I think AS is the last major bit of code that needs to be moved out into its own<br></div><div>service. Tho' hopefully still using Heat to orchestrate.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
<br>
Option B: Bottom-Up Slow Growth<br>
-------------------------------<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>
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>
<br></blockquote><div><br><br></div><div>At summit people were leaning towards "B", but I am very tempted by the<br></div><div>potential speed of development of "A" and the reduced code churn on the heat<br>repo (assuming we pull it out into a new repo). Given the other code churn<br></div><div>going on in our code base (convergence) it might make non stop AS rework<br></div><div>difficult to manage.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There could be option C, D... but the two above are what we came up with<br>
during the discussion.<br>
<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><div><br></div><div>I think a mixture of here (mailing list) and the weekly meeting should be ok<br></div><div>to getting some consensus about the way forward.<br><br></div><div>-Angus<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks.<br>
<br>
Regards,<br>
 Qiming<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>