OpenStack Shared File Systems Service (Manila)

Bug #1499743
Comment #3

Comment 3 for bug 1499743

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2015-10-01: 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)

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 <ikke@nicolast.be>
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)