The openstack-common project intends to produce a python library containing infrastructure code shared by OpenStack projects. The APIs provided by the project should be high quality, stable, consistent and generally useful.
The existence of an API in openstack-common should be indicitative of rough consensus across the project on that API's design. New OpenStack projects should be able to use an API in the library safe in the knowledge that, by doing so, the project is being a good OpenStack citizen and building upon established best practice.
To that end, a number of principles should be adhered to when considering any proposed API for openstack-common:
- The API is generally useful and is a "good fit" - e.g. it doesn't encode some assumptions specific to the project it originated from, it should follow a style consistent with other openstack-common APIs and should fit generally in a theme like error handling, configuration options, time and date, notifications, WSGI, etc.
- The API is already in use by a number of OpenStack projects
- There is a commitment to adopt the API in all other OpenStack projects (where appropriate) and there are no known major blockers to that adoption
- The API represents the "rough consensus" across OpenStack projects
- There is no other API in OpenStack competing for this "rough consensus"
- It should be possible for the API to evolve while continuing to maintain backwards compatibility with older versions for a reasonable period - e.g. compatibility with an API deprecated in release N may only be removed in release N+2
There have been several attempts at kick-starting openstack-common, each attempt beginning with moving a number of existing APIs from Glance or Nova into a new repository. None of these attempts have quite managed to reach the point where they were ready for other OpenStack projects to depend on the library.
This proposal marks the beginning of yet another attempt. The idea is to create a new openstack-common repository, seed it with Jason Kölker's excellent infrastructure from his repository and begin importing individual APIs while applying the principles above during the review process for each proposed API.