On Fri, Nov 28, 2014 at 5:33 PM, Qiming Teng <[email protected]> wrote:
> 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 > BPs: > - 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/as-api-webhook-trigger-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 > > Pros: > - Separate code base means faster review/commit cycle > - Less code churn in Heat > Cons: > - A new service need to be installed/configured/launched > - Need commitments from dedicated, experienced developers from very > beginning > > 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...) > > Pros: > - Less risk breaking user lands with each revision well tested > - More smooth transition for users in terms of upgrades > > Cons: > - 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 > welcomed. > I think a mixture of here (mailing list) and the weekly meeting should be ok to getting some consensus about the way forward. -Angus > > Thanks. > > Regards, > Qiming > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
