[openstack-dev] [oslo] The right (and the wrong) way of handling module imports in oslo-incubator

Ihar Hrachyshka ihrachys at redhat.com
Fri Nov 14 09:31:58 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 14/11/14 09:14, Flavio Percoco 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.

Crazy idea: we should have a bot that -1's all the patches that modify
oslo-incubator code without being marked by some special tag
(OsloSync?). We've slipped several local modifications to those files
before (I know two cases in Neutron, though I hardly monitor all the
patch queue).

> 
> 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.
> 
> 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.
> 
> 
> 
> _______________________________________________ OpenStack-dev
> mailing list OpenStack-dev at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUZcwOAAoJEC5aWaUY1u5741wH/2B/Pf56YtAaru7jAR9bN7IZ
KNY2zkGIDNMZQJWz3DxW7R0myKdmHVqrM/wA+8Lkf0l/ITh1LtiXtRxx5E2sPnJP
jef3ODTESooOKGcGOxvKO8tt/Bl4EorJzkX70dyJzlV7fKfZuwCFpZCp73S7npBh
BYd5Dfhi+pTyIZvtWSYKJzloJ/BasvKM+pwvlVsV9JIwMNrwwaLx2yDh+D3fltEg
bROJooq5J6z/pN19bZ5UkFU2z9lHNI6K6pa1eWLqQdm8WJnNmfmJjiX+vO2wp1z5
7qDsKL/dbHzXfPrBX8MqO9SEvt/jrDS8TeA2tMgAZg8+F5ST1dVHFGxWXJ4eoF4=
=2v6F
-----END PGP SIGNATURE-----



More information about the OpenStack-dev mailing list