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 <p...@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 <gkot...@vmware.com> wrote: >> >> Should we not be updating this in the requirements project? >> >> From: Paul Michali <p...@michali.net> >> Reply-To: OpenStack List <email@example.com> >> Date: Tuesday, December 1, 2015 at 4:50 PM >> To: OpenStack List <firstname.lastname@example.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 <p...@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-requ...@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-requ...@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@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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev