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

Jay S. Bryant jsbryant at electronicjungle.net
Fri Nov 14 13:56:24 UTC 2014


On 11/14/2014 03:31 AM, Ihar Hrachyshka wrote:
> -----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).
We had this problem a lot in Cinder in the past.  With education and 
monitoring from the Cores we have been able to avoid it.  The idea of 
monitoring for such commits is a good idea.  I wonder, however, if there 
is a way to do it with a hacking check?

>
>> 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-----
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list