Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.
This topic will cover two topics related to Code Management within Keystone. The first is API Deprecation (Internal API Stabilization as well as V2 and future deprecation paths). The second will be Extension mechanisms [use of stevedore, paste, and alembic].
API Stabilization and Deprecation: Keystone has seen a large amount of shift in the internal APIs over the course of Havana. From that standpoint, it is important to be able to elegantly deprecate these internal APIs in a controlled manner to better support developers and consumers that implement custom code that hooks into keystone (be it a driver, a plugin, or something totally different). The scope of the deprecation should probably be for a single release (e.g. if the interface was deprecated/moved/changed/etc during the Havana cycle, in Icehouse the "deprecated" warning or stub-compat function would be removed). This session should also touch on the public facing APIs and the deprecation mechanism/choices (see the linked blueprint).
ML topic can be seen here: http://lists.openstack.org/pipermail/openstack-dev/2013-October/016704.html
Extension Mechanisms: The second part of this session will cover the use of the various tools to pull together Keystone and it's extensions. This will cover the use of stevedore, alembic, paste, etc. This is to make sure we are on the same page for handling extension detection both integrated and out-of-tree development. We will also address what is to become core versus strictly extensions (and how this is determined) and how we determine if an extension should become more than an extension.
