Open Stack

Operationally they'll need to be able to make the change in a way that
it can be sequenced. We don't have a concept of simultaneous tied
changes. So a the change you describe would need to look like:

Land change to openstack-common to add something new
Land changes to dependent projects to use that new thing
Land change to openstack-common to remove now deprecated thing.

As a related note, I'm going to get the current repo moved in to gerrit
today or tomorrow.

Monty

On 01/03/2012 11:54 AM, Ewan Mellor wrote:
> 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
> _______________________________________________
> 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
>