neutron

TestNecPortBindingValidatePortInfo unit tests failing on longinteger conversion

Bug #1228212 reported by Matt Riedemann
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Undecided
Matt Riedemann
neutron 2013.2 "havana"

Bug Description

These two tests in neutron trunk are failing on my 64-bit xubuntu 12.04 using python 2.7:

http://paste.openstack.org/show/47323/

When I run the NECPluginV2._validate_portinfo method in python, I get this:

mriedem@ubuntu:~$ python
Python 2.7.3 (default, Aug 1 2012, 05:16:07)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> datapath_id = '0x1234567890abcdef'
>>> dpid = int(datapath_id, 16)
>>> dpid
1311768467294899695L
>>> dpid > 0xffffffffffffffffL
False
>>> hex(dpid)
'0x1234567890abcdefL'
>>>

So the int(datapath_id, 16) conversion is returning it as a longinteger, so the 'L' is appended at the end.

http://docs.python.org/2/library/functions.html#int

"If the argument is outside the integer range, the function returns a long object instead."

http://docs.python.org/2/reference/lexical_analysis.html#integers

I'm able to fix this in the tests by simply using assertIn rather than assertEqual:

self.assertIn('0x1234567890abcdef', portinfo['datapath_id'])

I'm not sure if this is a bug in the tests though or something that should be handled in the _validate_portinfo method, i.e. if you get past all of the current validation OK, then simply return the input argument in the dict that goes back.

Tags: unittest nec
Revision history for this message
ZhiQiang Fan (aji-zqfan) wrote :

i think assertIn cannot ensure the two integer is same

Revision history for this message
David Peraza (dperaza) wrote :

you can always do string replace on 'L' then keep doing the assertEqual

Revision history for this message
Matt Riedemann (mriedem) wrote :

I don't know why the gerrit review wasn't linked:

https://review.openstack.org/#/c/47598/

Comments are welcome there.

Changed in neutron:
status: New → In Progress
assignee: nobody → Matt Riedemann (mriedem)
Revision history for this message
Matt Riedemann (mriedem) wrote :

Looks like it's a py26 vs py27 issue, this is on python 2.6:

bash-4.1$ python
Python 2.6.6 (r266:84292, Aug 28 2012, 10:55:56)
[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> datapth_id = '0x123456789abcdef'
>>> dpid = int(datapth_id, 16)
>>> dpid
81985529216486895
>>> hex(dpid)
'0x123456789abcdef'
>>>

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

Reviewed: https://review.openstack.org/47598
Committed: http://github.com/openstack/neutron/commit/d4d06dfd18d8d085ccd390d6ebae7e3808fa8d09
Submitter: Jenkins
Branch: master

commit d4d06dfd18d8d085ccd390d6ebae7e3808fa8d09
Author: Matt Riedemann <email address hidden>
Date: Fri Sep 20 08:47:25 2013 -0700

    Handle long integer conversion in NEC portinfo validation tests

    There are a couple of tests for NEC portinfo validation that pass an id
    which gets converted to a base-16 integer and then that gets converted
    to a hex string. The problem is the integer conversion can make it a
    long integer and then the hex built-in appends 'L' to the string, and
    the tests do not account for that. This patch handles that case.

    Closes-Bug: #1228212

    Change-Id: Id3aed686329dae9cc4777213a4d2bcf406652e15

Changed in neutron:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in neutron:
milestone: none → havana-rc1
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in neutron:
milestone: havana-rc1 → 2013.2
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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