'test_trans_add' unit test broken on Python 3.4.3

Bug #1499743 reported by Nicolas Trangez
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Shared File Systems Service (Manila)
Fix Released
Critical
Nicolas Trangez

Bug Description

The `test_trans_add` test in `manila.tests.test_hacking.HackingTestCase`
consistently failed on our CI system, which is based on Ubuntu 14.04.
Contrary, on my development machine running Fedora 22, all tests
succeeded. Whilst the test dispatches on Python version (`if six.PY2`)
to select which `hacking` errors are expected, at which line/column
pair, I noticed our CI system returned the expected values for Python 2,
not the Python 3 ones, which differ in column numbers only.

After verifying versions of dependencies, stepping through the code and
whatnot, the only difference left turned out to be the version of Python
being used: 3.4.2 on my workstation, 3.4.3 on our CI system. As a last
resort, I opened the Python 3.4 ChangeLog [1] and noticed a suspicious
entry::

    Issue #21295: Revert some changes (issue #16795) to AST line numbers
    and column offsets that constituted a regression.

Looking at those issues, it becomes clear this is the cause. Supposedly
the Python 3 specific expected values were created on a Python 3.4
version containing the original patch of #16795 [2], and this is also
what's running on the OpenStack CI system. Our CI system runs a build of
Python which contains the revert of #21295 [3].

This patch fixes the version-specific expected error calculation by not
simply dispatching on Python 2 or 3, but specifically limits the custom
version to 3.4.0 <= Python < 3.4.3.

[1] https://docs.python.org/3.4/whatsnew/changelog.html
[2] http://bugs.python.org/issue16795
[3] http://bugs.python.org/issue21295

Changed in manila:
assignee: nobody → Nicolas Trangez (eikke)
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to manila (master)

Reviewed: https://review.openstack.org/227854
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=83167bd2a2a0369d2271bd08ebc7ca753a603d60
Submitter: Jenkins
Branch: master

commit 83167bd2a2a0369d2271bd08ebc7ca753a603d60
Author: Nicolas Trangez <email address hidden>
Date: Fri Sep 25 15:26:57 2015 +0200

    Fix `test_trans_add` for Python 3.4.3

    The `test_trans_add` test in `manila.tests.test_hacking.HackingTestCase`
    consistently failed on our CI system, which is based on Ubuntu 14.04.
    Contrary, on my development machine running Fedora 22, all tests
    succeeded. Whilst the test dispatches on Python version (`if six.PY2`)
    to select which `hacking` errors are expected, at which line/column
    pair, I noticed our CI system returned the expected values for Python 2,
    not the Python 3 ones, which differ in column numbers only.

    After verifying versions of dependencies, stepping through the code and
    whatnot, the only difference left turned out to be the version of Python
    being used: 3.4.2 on my workstation, 3.4.3 on our CI system. As a last
    resort, I opened the Python 3.4 ChangeLog [1] and noticed a suspicious
    entry::

        Issue #21295: Revert some changes (issue #16795) to AST line numbers
        and column offsets that constituted a regression.

    Looking at those issues, it becomes clear this is the cause. Supposedly
    the Python 3 specific expected values were created on a Python 3.4
    version containing the original patch of #16795 [2], and this is also
    what's running on the OpenStack CI system. Our CI system runs a build of
    Python which contains the revert of #21295 [3].

    This patch fixes the version-specific expected error calculation by not
    simply dispatching on Python 2 or 3, but specifically limits the custom
    version to 3.4.0 <= Python < 3.4.3.

    [1] https://docs.python.org/3.4/whatsnew/changelog.html
    [2] http://bugs.python.org/issue16795
    [3] http://bugs.python.org/issue21295

    Closes-Bug: 1499743

    Change-Id: I649fb1f5244efba7ab79e9bf337433d541fa8b19

Changed in manila:
status: In Progress → Fix Committed
tags: added: liberty-rc-porential
tags: added: liberty-rc-potential
removed: liberty-rc-porential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to manila (stable/liberty)

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/228199

Changed in manila:
importance: Undecided → Critical
Changed in manila:
milestone: none → mitaka-1
milestone: mitaka-1 → liberty-rc2
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to manila (stable/liberty)

Reviewed: https://review.openstack.org/228199
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=552a80a5bfa48e5c53e80c5fef10e08bfe62f614
Submitter: Jenkins
Branch: stable/liberty

commit 552a80a5bfa48e5c53e80c5fef10e08bfe62f614
Author: Nicolas Trangez <email address hidden>
Date: Fri Sep 25 15:26:57 2015 +0200

    Fix `test_trans_add` for Python 3.4.3

    The `test_trans_add` test in `manila.tests.test_hacking.HackingTestCase`
    consistently failed on our CI system, which is based on Ubuntu 14.04.
    Contrary, on my development machine running Fedora 22, all tests
    succeeded. Whilst the test dispatches on Python version (`if six.PY2`)
    to select which `hacking` errors are expected, at which line/column
    pair, I noticed our CI system returned the expected values for Python 2,
    not the Python 3 ones, which differ in column numbers only.

    After verifying versions of dependencies, stepping through the code and
    whatnot, the only difference left turned out to be the version of Python
    being used: 3.4.2 on my workstation, 3.4.3 on our CI system. As a last
    resort, I opened the Python 3.4 ChangeLog [1] and noticed a suspicious
    entry::

        Issue #21295: Revert some changes (issue #16795) to AST line numbers
        and column offsets that constituted a regression.

    Looking at those issues, it becomes clear this is the cause. Supposedly
    the Python 3 specific expected values were created on a Python 3.4
    version containing the original patch of #16795 [2], and this is also
    what's running on the OpenStack CI system. Our CI system runs a build of
    Python which contains the revert of #21295 [3].

    This patch fixes the version-specific expected error calculation by not
    simply dispatching on Python 2 or 3, but specifically limits the custom
    version to 3.4.0 <= Python < 3.4.3.

    [1] https://docs.python.org/3.4/whatsnew/changelog.html
    [2] http://bugs.python.org/issue16795
    [3] http://bugs.python.org/issue21295

    Closes-Bug: 1499743

    Change-Id: I649fb1f5244efba7ab79e9bf337433d541fa8b19
    (cherry picked from commit 83167bd2a2a0369d2271bd08ebc7ca753a603d60)

tags: added: in-stable-liberty
Thierry Carrez (ttx)
Changed in manila:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in manila:
milestone: liberty-rc2 → 1.0.0
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to manila (master)

Fix proposed to branch: master
Review: https://review.openstack.org/235328

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to manila (master)
Download full text (11.9 KiB)

Reviewed: https://review.openstack.org/235328
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=ec94d6929ea8e1b4ce10dc91cd4954ece808668c
Submitter: Jenkins
Branch: master

commit f1eded1fbcaf309e1c9a4be3f8a14bd25daa3e46
Author: Gaurang Tapase <email address hidden>
Date: Mon Oct 12 20:47:19 2015 +0530

    Fix usage of dependencies

    Manila is broken is threee places, so fix them:
    1) test 'test_misc' with WebOb 1.5

    WebOb 1.5 was released at 2015-10-11. With this new version,
    webob.exc.WSGIHTTPException() constructor now fails with a KeyError
    when the HTTP status code is 0.

    test_exceptions_raise() of test_misc tries to instantiate all
    exceptions of manila.exception. The problem is that
    ConvertedException uses a default HTTP status code of 0.

    Modify the default HTTP status code of ConvertedException to 400 to
    fix the unit tests.

    2) Add dependency for 'testresources' that is required by migration
    tests.

    3) Remove 2 unit tests related to testing of oslo.policy lib
    functionality that should not be tested in Manila. It started failing
    because under-the-hood behaviour was changed in new realese 0.12.0

    Closes-Bug: #1505153
    Closes-Bug: #1505374

    (cherry picked from commit 9c99814ce5943bd4c33bf3650b832666e31b3411)

    -- squashed with another change to get tests to pass on stable/liberty --

    Fix broken unit tests

    With release of six module version 1.10.0 several our unit tests
    started to fail because of usage of not strict constructions.

    Changes:
    1) Manila unit test
    "manila.tests.share.test_api.ShareAPITestCase.test_extend_quota_error"
    used str for int substitution. So, use int data for int substitution.

    2) Module 'manila.share.drivers.hp.hp_3par_mediator' was using
    LOG.exception function when no traceback were exist it led to
    AttributeError on py34. So, replace all usages of 'LOG.exception'
    with 'LOG.error' where no raised exceptions exist.

    Change-Id: Ic5b37bfb9d939d03f6ff68bc53d134bf9e5f996e
    Closes-Bug: #1503969
    (cherry picked from commit f38b8d4efd1f68f4ea29747f7377e0936f61d89c)

    --

    Change-Id: I0f28f3c3fb2c7eec1bafc3a617344990f86810cf

commit 151b691bb2d4baa436913924df60b8c197f91463
Author: Valeriy Ponomaryov <email address hidden>
Date: Thu Oct 1 12:42:05 2015 +0300

    Fix display of availability-zone for manila-manage command

    Commands "manila-manage service list" and "manila-manage host list"
    were displaying availability zone instance instead of its name.

    Such bug appeared after implementation of Availability zone model.
    So, fix it by providing 'name' field of availability zone model.

    Change-Id: I14c3451380df01853183aed265344b1783c95939
    Closes-Bug: #1499677

commit 77455a5ac6be828e8dfd3e75566eaff2823595d4
Author: Csaba Henk <email address hidden>
Date: Wed Sep 30 14:57:00 2015 +0200

    glusterfs_native: use dynamic-auth option if available

    With dynamic-auth restarting the volume is not necessary
    in deny_access.

    Change-Id: Ic25af1795c279b34370...

Revision history for this message
Doug Hellmann (doug-hellmann) wrote : Fix included in openstack/manila 2.0.0.0b1

This issue was fixed in the openstack/manila 2.0.0.0b1 development milestone.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.