[openstack-dev] [neutron][neutron-*] Notice! pylint breakage

Gareth academicgareth at gmail.com
Fri Feb 5 09:16:30 UTC 2016


Thanks for all!

However I'm developing on stable/liberty and it failed with running
"tox -e pep8" because of this issue. And I found it is pylint==1.4.5
on master branch. Could we cherry-pick this test-requirements update
back to stable/liberty?

On Wed, Dec 2, 2015 at 12:04 AM, Paul Michali <pc at michali.net> wrote:
> Infra did not want to update requirements for master.
>
> I found a solution for VPN on master, namely pinning pylint and astroid in
> tox.ini (we already have a dependency for pylint in tox.ini).
>
> I'm thinking that for VPN on Kilo, we could cherry pick that change, rather
> than employ https://review.openstack.org/#/c/251874/, which needs the fix to
> requirements project.
>
> Thoughts?
>
> PCM
>
> On Tue, Dec 1, 2015 at 10:29 AM Gary Kotton <gkotton at vmware.com> wrote:
>>
>> Should we not be updating this in the requirements project?
>>
>> From: Paul Michali <pc at michali.net>
>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
>> Date: Tuesday, December 1, 2015 at 4:50 PM
>> To: OpenStack List <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [neutron][neutron-*] Notice! pylint breakage
>>
>> Some additional info...
>>
>> astroid upstream folks are going to try to push for pylint 1.4.5 that pins
>> to astroid 1.3.8. If that happens, we could just pin pylint at 1.4.5. Ref:
>> https://bitbucket.org/logilab/astroid/issues/275/140-and-141-fail-to-work-with-pylint-144
>>
>> It sounds like we don't need to pin versions for Juno. My attempt seems to
>> be failing tests (badly) https://review.openstack.org/#/c/251865.
>>
>> The neutron kilo patch seems ready to go, once the infra commit is
>> upstreamed: https://review.openstack.org/#/c/251827/
>>
>> Infra commits are: https://review.openstack.org/#/c/251599/ (juno) and
>> https://review.openstack.org/#/c/251600/ (kilo). Need to (at least) get kilo
>> upstreamed.
>>
>> For master, LB and VPN repos are broken. I can see these options
>>
>> implement pep8 constraints (takes time)
>> ignore pylint errors/warnings until do #1  (less coverage)
>> disable pylint until do #1 (no coverage)
>> Fix the pylint 1.5.0 errors (will be an issue when go to pylint 1.4.4 as
>> part of #1)
>>
>> I'm thinking #2 is the least intrusive, and will try that for VPN repo.
>>
>> BTW: FW repo does not do 'pylint' as part of pep8 (essentially #3 option)
>> currently, so they don't see this carnage.
>>
>>
>> Regards,
>>
>> Paul Michali (pc_m)
>>
>> On Tue, Dec 1, 2015 at 6:44 AM Paul Michali <pc at michali.net> wrote:
>>>
>>> I found a problem yesterday running pep8 locally in neutron-lbaas. After
>>> discussing with LBaaS team, we identified that there is a problem with
>>> pylint.  The same issues were seen, when hecking in neutron and
>>> neutron-vpnaas repos (need to check neutron-fwaas). There are two issues
>>> seen.
>>>
>>> First, the new version of pylint (1.5.0) is finding additional
>>> warnings/errors. This will require updates to code, to be compliant with the
>>> new pylint (assuming we move up to that version). I did see one case where
>>> the changes needed for pylint 1.5.0 are backward incompatible with pylint
>>> 1.4.4, which raises another concern (how to migrate to newer pylint).
>>>
>>> Second, pylint uses the astroid package, which was recently update from
>>> 1.3.8 to 1.4.1. When used with pylint 1.4.4 (the currently used version in
>>> neutron), we get all sorts of false positive errors. For example, use of
>>> each imported module shows a "undefined variable" error.
>>>
>>> In neutron-vpnaas, this issue is worse, as pylint iand astroid are not
>>> pinned to any version, so it can update at unexpected times.
>>>
>>> After talking to infra, here are the proposed solutions...
>>>
>>> Neutron - In pretty good shape
>>>
>>> The pep8-constraints job currently works, as global requirements in
>>> pylint to 1.4.4 and upper constraints pin astroid to 1.3.8 - both work
>>> together well.  Locally, one needs to use pep8-constraints and not pep8, as
>>> the latter will pull in the latest astroid (1.4.1) and cause havoc.
>>>
>>> Infra is pushing up two commits to global requirements to pin astroid to
>>> 1.3.8 for kilo (251600) and juno (251599). We need to pin astroid to 1.3.8
>>> in test-requirements.txt for those branches. I'll start on that in a few
>>> minutes.
>>>
>>> LBaaS/VPNaaS/FWaas? - Needs constraints
>>>
>>> For pep8 jobs, these repos need to use the new pep8-constraints style job
>>> and tox.ini should also use the same target, instead of pep8. Like neutron,
>>> kilo and juno branches need to pin astroid to 1.3.8.
>>>
>>> neutron-vpnaas should also pin pylint to 1.4.4 in test-requirements.txt,
>>> to prevent it from floating to 1.5.0.
>>>
>>> All repos will need a plan for updating code to conform to pylint 1.5.0,
>>> if/when we upgrade to this.
>>>
>>> Note: I have not looked at neutron-fwaas, so we need to confirm the above
>>> issue is present, but it likely is (even if there is not a current pylint
>>> failure).
>>>
>>> One concern I have, that infra hasn't figured out how it can be
>>> addressed, is how we'll update to pylint 1.5.0. If were are using
>>> pep8-constraints, the constraints file is in a different repo. Updating, to
>>> say, pylint 1.5.0 and astroid 1.4.1, would cause breakage until both the
>>> neutron* repos and requirements repo are updated.  This is complicated with
>>> backward incompatible changes needed.
>>>
>>> Thanks to blogan, ZZelle, fungi, anteaya, lifeless, ajmiller and others
>>> for helping investigate and come up with the approach on this issue!
>>>
>>> Regards,
>>>
>>> Paul Michali (pc_m)
>>>
>>>
>> __________________________________________________________________________
>> 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
>



-- 
Gareth (Kun Huang)

Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball
OpenStack contributor, kun_huang at freenode
My promise: if you find any spelling or grammar mistakes in my email
from Mar 1 2013, notify me
and I'll donate $1 or ¥1 to an open organization you specify.



More information about the OpenStack-dev mailing list