Open Stack

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?

Ewan. 

> -----Original Message-----
> From: openstack-bounces+ewan.mellor=citrix.com at lists.launchpad.net
> [mailto:openstack-bounces+ewan.mellor=citrix.com at lists.launchpad.net]
> On Behalf Of Mark McLoughlin
> Sent: 03 January 2012 08:58
> To: openstack at lists.launchpad.net
> Cc: Jason Koelker
> Subject: [Openstack] openstack-common
> 
> Hey,
> 
> As Jason says - another year, another openstack-common thread! :-)
> 
> I've just written up the plan Jason and I have for openstack-common:
> 
>    http://wiki.openstack.org/CommonLibrary
> 
> (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
> a
> handful of APIs, but they meet the criteria below, then we'll have a
> really solid foundation to build on.
> 
> Thoughts?
> 
> Cheers,
> Mark.
> 
> 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:
> 
>   1) 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.
> 
>   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
> projects
>      (where appropriate) and there are no known major blockers to that
> adoption
> 
>   4) The API represents the "rough consensus" across OpenStack projects
> 
>   5) There is no other API in OpenStack competing for this "rough
> consensus"
> 
>   6) 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[1] and begin importing individual
> APIs while applying the principles above during the review process for
> each proposed API.
> 
> [1] - https://github.com/jkoelker/openstack-common
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp