Description of problem: The following unit tests fail every single build neutron.tests.unit.objects.qos.test_rule_type.QosRuleTypeObjectTestCase.test_object_version neutron.tests.unit.objects.qos.test_policy.QosPolicyDbObjectTestCase.test_object_version_degradation_1_5_to_1_4_egress_direction neutron.tests.unit.objects.qos.test_policy.QosPolicyDbObjectTestCase.test_object_version_degradation_to_1_0 neutron.tests.unit.objects.qos.test_policy.QosPolicyDbObjectTestCase.test_object_version_degradation_1_3_to_1_2 neutron.tests.unit.objects.qos.test_policy.QosPolicyDbObjectTestCase.test_object_version_degradation_1_2_to_1_1 neutron.tests.unit.objects.qos.test_policy.QosPolicyDbObjectTestCase.test_object_version_degradation_1_5_to_1_4_ingress_direction neutron.tests.unit.objects.qos.test_rule_type.QosRuleTypeObjectTestCase.test_object_version_degradation_1_3_to_1_2 Traceback (most recent call last): File "neutron/tests/base.py", line 118, in func return f(self, *args, **kwargs) File "neutron/tests/unit/objects/qos/test_policy.py", line 503, in test_object_version_degradation_1_5_to_1_4_ingress_direction policy_obj_v1_4 = self._policy_through_version(policy_obj, '1.4') File "neutron/tests/unit/objects/qos/test_policy.py", line 426, in _policy_through_version return policy.QosPolicy.clean_obj_from_primitive(primitive) File "neutron/objects/base.py", line 148, in clean_obj_from_primitive obj = cls.obj_from_primitive(primitive, context) File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line 414, in obj_from_primitive objclass = cls.obj_class_from_name(objname, objver) File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line 377, in obj_class_from_name vutils.is_compatible(objver, objclass.VERSION)): File "/usr/lib/python2.7/site-packages/oslo_utils/versionutils.py", line 45, in is_compatible if same_major and (requested_parts[0] != current_parts[0]): TypeError: 'Version' object does not support indexing How reproducible: 100% Steps to Reproduce: 1. Run latest OSP 12 neutron unit tests on Fedora or RHEL
OSP 10 and 11 are also affected
Upstream is busted too
Upstream recap mail: http://lists.openstack.org/pipermail/openstack-dev/2018-March/128529.html
This bug has been fixed upstream in oslo.utils 3.28.2 (for OpenStack Pike, OSP 12): * https://review.openstack.org/#/c/554053/ * https://bugs.launchpad.net/oslo.utils/+bug/1706394 oslo.utils will be upgraded to 3.28.2 as the next "Rebase" batch. The previous batch upgraded it to 3.28.1: bz#1545607 See also bz#1561020 which is the same bug. This bz has been marked as NOTABUG, since the issue was caused by setuptools upgraded manually using pip in an Ansible playbook.
"QOS unit tests fail with TypeError: ..." Please check if setuptools is upgraded manually to the latest version. I bet that setuptools was upgraded manually using pip, and not properly installed from a RPM package. The workaround is to prevent upgrading setuptools using pip. Usually, it's not a good practice to upgrade a Python module using pip when it has been installed by RPM.
(In reply to Victor Stinner from comment #7) > This bug has been fixed upstream in oslo.utils 3.28.2 (for OpenStack Pike, > OSP 12): > > * https://review.openstack.org/#/c/554053/ > * https://bugs.launchpad.net/oslo.utils/+bug/1706394 > > oslo.utils will be upgraded to 3.28.2 as the next "Rebase" batch. The > previous batch upgraded it to 3.28.1: bz#1545607 > > See also bz#1561020 which is the same bug. This bz has been marked as > NOTABUG, since the issue was caused by setuptools upgraded manually using > pip in an Ansible playbook. Shouldn't we wait here for downstream rebase to 3.28.2 that contains the workaround for cases where setuptools was actually upgraded by pip?
That's my plan: wait for downstream rebase to 3.28.2.
python-oslo-utils-3.28.2-1.el7ost package is now available for tests.
Works fine now :)
I updated the DocText field.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:2521