Open Stack

On Nov 14, 2014, at 3:14 AM, Flavio Percoco <flavio at redhat.com> wrote:

> On 13/11/14 23:25 +0000, Amrith Kumar wrote:
>> At the suggestion of Doug Hellmann, and relative to a conversation with him and
>> Flavio at Summit. Doug suggested that I pose this question on the dev mailing
>> list so someone from OSLO can communicate the answer to the entire community
>> (rather than just the private email exchange that we had).
>> 
>> 
>> Here’s the situation, I’m using loopingcall.py as an example, this is not
>> limited to this module but serves as an example.
>> 
>> 
>> An OSLO incubator module loopingcall depends on another OSLO incubator module
>> timeutils.
>> 
>> 
>> timeutils has graduated [drum-roll] and is now part of oslo.utils.
>> 
>> 
>> There is also other project code that references timeutils.
>> 
>> 
>> So, to handle the graduation of timeutils, the changes I’ll be making are:
>> 
>> 
>> 1.  Remove timeutils from openstack-common.conf
>> 
>> 2.  Make the project code reference oslo.utils
>> 
>> 
>> But what of loopingcall? Should I
>> 
>> 
>> a.  Update it and change the import(s) therein to point to oslo.utils, or
>> 
>> b.  Sync the oslo-incubator code for loopingcall, picking up all changes at
>> least upto and including the change in oslo-incubator that handles the
>> graduation of oslo.utils.
>> 
>> 
>> In speaking with Doug and Flavio, (after I submitted copious amounts of code
>> that did (a)) above, I’ve come to learn that I chose the wrong answer. The
>> correct answer is (b). This doesn’t have to be part of the same commit, and
>> what I’ve ended up doing is this …
>> 
>> 
>> c.  Leave timeutils in <project>/openstack/common and let oslo-incubator depend
>> on it while migrating the project to use oslo.utils. In a subsequent commit, a
>> sync from oslo-incubator can happen.
>> 
>> 
>> I’d like someone on OSLO to confirm this, and for other projects whose lead I
>> followed, you may want to address these in the changes you have in flight or
>> have already merged.
>> 
> 
> `b` is the right answer there. As a general rule - probably the
> easiest way to solve the above dilema - people should *never* modify
> incubator modules in the project. Sticking to this rule will
> automatically answer the question of how to update, maintain and
> consume code from oslo-incubator.

Yes, that’s right. We’ve worked very hard to ensure that the incubator always works with released Oslo libraries specifically so projects will not have to hack up versions of those modules in order to adopt the libraries. That will, at times, mean you have to adopt multiple libraries in a single patch. This is annoying from a “one patch, one change” standpoint, but it preferable from the “always keep master working” standpoint. After Kilo, the rate of graduations will drop off significantly and so this won’t be an issue any more. Please bear with us in the mean time.

> If there are projects that picked `a` as the right answer, please,
> update your patches and follow the already well defined workflow for
> oslo-incubator. Doing otherwise will just make things harder for us
> who maintain oslo, for stable maintenance and for your own
> contributors.

The Oslo team is under no obligation to support Oslo code modified outside of an Oslo code repository. I don’t know what stand the stable maintenance team takes on the subject, but I would expect them similarly to insist on following community practices.

Doug

> 
> Amrith, thanks for bringing this up and for updating your patches, I know it's
> a pain and I appreciate your collaboration there.
> 
> Cheers,
> Flavio
> 
> P.S: Gentle note. Oslo is not an acronym.
> 
> -- 
> @flaper87
> Flavio Percoco
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev