Open Stack

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
> <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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151201/509c52bd/attachment.html>