[openstack-dev] [Heat] Rework auto-scaling support in Heat
asalkeld at mirantis.com
Sat Nov 29 04:38:04 UTC 2014
On Fri, Nov 28, 2014 at 5:33 PM, Qiming Teng <tengqim at linux.vnet.ibm.com>
> Dear all,
> Auto-Scaling is an important feature supported by Heat and needed by
> many users we talked to. There are two flavors of AutoScalingGroup
> resources in Heat today: the AWS-based one and the Heat native one. As
> more requests coming in, the team has proposed to separate auto-scaling
> support into a separate service so that people who are interested in it
> can jump onto it. At the same time, Heat engine (especially the resource
> type code) will be drastically simplified. The separated AS service
> could move forward more rapidly and efficiently.
> This work was proposed a while ago with the following wiki and
> blueprints (mostly approved during Havana cycle), but the progress is
> slow. A group of developers now volunteer to take over this work and
> move it forward.
Thank you for taking on this big project!
> wiki: https://wiki.openstack.org/wiki/Heat/AutoScaling
> - https://blueprints.launchpad.net/heat/+spec/as-lib-db
> - https://blueprints.launchpad.net/heat/+spec/as-lib
> - https://blueprints.launchpad.net/heat/+spec/as-engine-db
> - https://blueprints.launchpad.net/heat/+spec/as-engine
> - https://blueprints.launchpad.net/heat/+spec/autoscaling-api
> - https://blueprints.launchpad.net/heat/+spec/autoscaling-api-client
> - https://blueprints.launchpad.net/heat/+spec/as-api-group-resource
> - https://blueprints.launchpad.net/heat/+spec/as-api-policy-resource
> - https://blueprints.launchpad.net/heat/+spec/autoscaling-api-resources
> Once this whole thing lands, Heat engine will talk to the AS engine in
> terms of ResourceGroup, ScalingPolicy, Webhooks. Heat engine won't care
> how auto-scaling is implemented although the AS engine may in turn ask
> Heat to create/update stacks for scaling's purpose. In theory, AS
> engine can create/destroy resources by directly invoking other OpenStack
> services. This new AutoScaling service may eventually have its own DB,
> engine, API, api-client. We can definitely aim high while work hard on
> real code.
Yes, I think AS is the last major bit of code that needs to be moved out
into its own
service. Tho' hopefully still using Heat to orchestrate.
> After reviewing the BPs/Wiki and some communication, we get two options
> to push forward this. I'm writing this to solicit ideas and comments
> from the community.
> Option A: Top-Down Quick Split
> This means we will follow a roadmap shown below, which is not 100%
> accurate yet and very rough:
> 1) Get the separated REST service in place and working
> 2) Switch Heat resources to use the new REST service
> - Separate code base means faster review/commit cycle
> - Less code churn in Heat
> - A new service need to be installed/configured/launched
> - Need commitments from dedicated, experienced developers from very
> Option B: Bottom-Up Slow Growth
> The roadmap is more conservative, with many (yes, many) incremental
> patches to migrate things carefully.
> 1) Separate some of the autoscaling logic into libraries in Heat
> 2) Augment heat-engine with new AS RPCs
> 3) Switch AS related resource types to use the new RPCs
> 4) Add new REST service that also talks to the same RPC
> (create new GIT repo, API endpoint and client lib...)
> - Less risk breaking user lands with each revision well tested
> - More smooth transition for users in terms of upgrades
> - A lot of churn within Heat code base, which means long review cycles
> - Still need commitments from cores to supervise the whole process
At summit people were leaning towards "B", but I am very tempted by the
potential speed of development of "A" and the reduced code churn on the heat
repo (assuming we pull it out into a new repo). Given the other code churn
going on in our code base (convergence) it might make non stop AS rework
difficult to manage.
> There could be option C, D... but the two above are what we came up with
> during the discussion.
> Another important thing we talked about is about the open discussion on
> this. OpenStack Wiki seems a good place to document settled designs but
> not for interactive discussions. Probably we should leverage etherpad
> and the mailinglist when moving forward. Suggestions on this are also
I think a mixture of here (mailing list) and the weekly meeting should be ok
to getting some consensus about the way forward.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev