[openstack-dev] [neutron][neutron-*] Notice! pylint breakage
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.
> 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:
>> 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
>> 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.
>> 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
>>> 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
>>> 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
>>> 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!
>>> Paul Michali (pc_m)
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
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