[openstack-dev] [Neutron] [neutron-lib] adding a new flag to neutron-lib

Doug Wiegley dougwig at parksidesoftware.com
Mon Mar 14 18:18:01 UTC 2016


tl;dr is, if you need a new constant/method/whatnot quickly, it should go into *neutron*, not *neutron-lib*.

The lib is meant to be for stable interfaces that are being used in more than one place. As such, I don’t think it should be the first stop for anything, nor should you ever set yourself up to wait for a change there. The lib is meant to encapsulate stable interfaces, but not to slow down neutron development. The general procedure that was envisioned is:

1. Make your change in neutron. ALL of it. If it’s a “common” routing, put it in a common place in neutron.  neutron-lib is NOT meant to replace the neutron repo having common utilities of its own.
2. If another project/repo needs that change, then propose it to the lib.
3. At some point it’ll merge and then be released, which will lag, on purpose.
4. Make the change in neutron to use the lib code, or file a bug for a lib maintainer to take care of it.

You can invert steps 3 and 4, it just won’t merge until the code is released on pypi.

You should *NOT* put yourself in a position where you need code to land and merge in neutron-lib before you can continue with neutron work. That is not what it’s meant for, and will slow people down too much, even if reviews in the lib happened at a lightning pace. And they shouldn’t, because rushing and deadlines lead to sloppy interfaces.

Now, all that said, there is an experimental job that builds neutron against lib master instead of pypi, that you can use to make sure changes work there if you wish. Couple that with Depends-On to get the test behavior requested.  But, please, don't get yourself into a position where that is blocking.

doug


> On Mar 14, 2016, at 12:01 PM, Assaf Muller <assaf at redhat.com> wrote:
> 
> On Mon, Mar 14, 2016 at 1:27 PM, Gary Kotton <gkotton at vmware.com> wrote:
>> Hi,
>> It would be nice if we could get a little more reviews in the neutron-lib.
>> I think that we should maybe strive to cut a new version prior to the
>> release.
>> Thanks
>> Gary
>> 
>> On 3/14/16, 6:17 PM, "Venkata Anil" <vkommadi at redhat.com> wrote:
>> 
>>> Hi All
>>> 
>>> I have added a new flag in neutron-lib
>>> https://review.openstack.org/#/c/291641/3/neutron_lib/constants.py
>>> and wanted to use that flag in neutron's change
>>> https://review.openstack.org/#/c/291651/
>>> How to add the dependency?
>>> 
>>> I added neutron-lib change in neutron's change as "Depends-On:" in
>>> commit message.
>>> Also added the change suggested in
>>> https://wiki.openstack.org/wiki/Neutron/Lib as  "Depends-On:" in commit
>>> message. But still neutron change is not resolving the flag added in
>>> neutron-lib.
> 
> On a somewhat related note, I'd love to pick the brains of the people
> involved as for why a separate repo was chosen over placing the code
> in the main Neutron repo (Under say, neutron.lib). It would mean
> easier/faster movement of code in to the lib, thus faster velocity and
> adoption. As it is, it requires 1 patch to move something in to
> neutron_lib (With a debtcollector), releasing a new version of it to
> PyPi, then another patch to use the code in Neutron. The Tempest
> community moved from tempest_lib to tempest.lib very recently, but I
> don't know all of the motivations behind that move, I can imagine the
> reason I stated above was also on their minds.
> 
>>> 
>>> Thanks
>>> Anil
>>> 
>>> 
>>> 
>>> 
>>> 
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list