openstack team mailing list archive
Mailing list archive
I'd love to see openstack-common get off the ground, so I'm all in favor of this.
One question: why do you feel that you need such strong backwards compatibility? If someone makes a change in openstack-common and makes simultaneous changes in all OpenStack projects to match, isn’t that sufficient?
> -----Original Message-----
> From: openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx
> On Behalf Of Mark McLoughlin
> Sent: 03 January 2012 08:58
> To: openstack@xxxxxxxxxxxxxxxxxxx
> Cc: Jason Koelker
> Subject: [Openstack] openstack-common
> As Jason says - another year, another openstack-common thread! :-)
> I've just written up the plan Jason and I have for openstack-common:
> (also pasted below to make it easier to reply to)
> I guess what we're trying to do is quickly get this thing into good
> enough shape to do a first release. Even if that release only contains
> handful of APIs, but they meet the criteria below, then we'll have a
> really solid foundation to build on.
> The openstack-common project intends to produce a python library
> infrastructure code shared by OpenStack projects. The APIs provided by
> project should be high quality, stable, consistent and generally
> The existence of an API in openstack-common should be indicitative of
> 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
> best practice.
> To that end, a number of principles should be adhered to when
> considering any
> proposed API for openstack-common:
> 1) The API is generally useful and is a "good fit" - e.g. it doesn't
> some assumptions specific to the project it originated from, it
> follow a style consistent with other openstack-common APIs and
> fit generally in a theme like error handling, configuration
> time and date, notifications, WSGI, etc.
> 2) The API is already in use by a number of OpenStack projects
> 3) There is a commitment to adopt the API in all other OpenStack
> (where appropriate) and there are no known major blockers to that
> 4) The API represents the "rough consensus" across OpenStack projects
> 5) There is no other API in OpenStack competing for this "rough
> 6) It should be possible for the API to evolve while continuing to
> 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
> infrastructure from his repository and begin importing individual
> APIs while applying the principles above during the review process for
> each proposed API.
>  - https://github.com/jkoelker/openstack-common
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp