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 <openstack-dev@lists.openstack.org> > Date: Tuesday, December 1, 2015 at 4:50 PM > To: OpenStack List <openstack-dev@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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_logilab_astroid_issues_275_140-2Dand-2D141-2Dfail-2Dto-2Dwork-2Dwith-2Dpylint-2D144&d=BQMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=gl1v9FdSQ7rYUO4HlbGDJ_28lT07a9Thah_ecaHzIbw&s=jvBDSbNi3dDG_83LBVa3sOpfq49Rk0gnSAzzsxGLD2U&e=> > > 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 > > 1. implement pep8 constraints (takes time) > 2. ignore pylint errors/warnings until do #1 (less coverage) > 3. disable pylint until do #1 (no coverage) > 4. 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
