Tests failed when using floating as connect_method

Bug #1686664 reported by Zhenyu Zheng
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tempest
Fix Released
High
Zhenyu Zheng

Bug Description

Tests
tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_attach_detach_volume[id-52e9045a-e90d-4c0d-9087-79d657faffff]
tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_list_get_volume_attachments[id-7fa563fe-f0f7-43eb-9e22-a1ece036b513]
are under the same class, so when these tests setup, and using floating as connect_method only one floating IP was created.We first associated it to instance created at test1 and then we created another instance in test2 and tried to associate this IP again to the new server, since the IP was already associated to instance created in test1, error will happen when try to do this.

Actually this tests are about volumes, there is no need to create two instances for these tests, just create one instance and use it for all the tests.

Test Log:
tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_list_get_volume_attachments[id-7fa563fe-f0f7-43eb-9e22-a1ece036b513]
---------------------------------------------------------------------------------------------------------------------------------------------

Captured traceback:
~~~~~~~~~~~~~~~~~~~
    Traceback (most recent call last):
      File "/home/defcore/refstack-client-master/.tempest/tempest/api/compute/volumes/test_attach_volume.py", line 163, in test_list_get_volume_attachments
        self._create_and_attach()
      File "/home/defcore/refstack-client-master/.tempest/tempest/api/compute/volumes/test_attach_volume.py", line 73, in _create_and_attach
        adminPass=self.admin_pass)
      File "/home/defcore/refstack-client-master/.tempest/tempest/api/compute/base.py", line 229, in create_test_server
        **kwargs)
      File "/home/defcore/refstack-client-master/.tempest/tempest/common/compute.py", line 157, in create_test_server
        % server['id'])
      File "/home/defcore/refstack-client-master/.tempest/.venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
        self.force_reraise()
      File "/home/defcore/refstack-client-master/.tempest/.venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise
        six.reraise(self.type_, self.value, self.tb)
      File "/home/defcore/refstack-client-master/.tempest/tempest/common/compute.py", line 147, in create_test_server
        server_id=servers[0]['id'])
      File "/home/defcore/refstack-client-master/.tempest/tempest/lib/services/compute/floating_ips_client.py", line 76, in associate_floating_ip_to_server
        resp, body = self.post(url, post_body)
      File "/home/defcore/refstack-client-master/.tempest/tempest/lib/common/rest_client.py", line 270, in post
        return self.request('POST', url, extra_headers, headers, body, chunked)
      File "/home/defcore/refstack-client-master/.tempest/tempest/lib/services/compute/base_compute_client.py", line 48, in request
        method, url, extra_headers, headers, body, chunked)
      File "/home/defcore/refstack-client-master/.tempest/tempest/lib/common/rest_client.py", line 668, in request
        resp, resp_body)
      File "/home/defcore/refstack-client-master/.tempest/tempest/lib/common/rest_client.py", line 771, in _error_checker
        raise exceptions.BadRequest(resp_body, resp=resp)
    tempest.lib.exceptions.BadRequest: Bad request
    Details: {u'message': u'Unable to associate floating ip 46.30.2.0 to fixed ip 192.168.0.126 for instance a6e6ffa1-1504-49b1-a035-9ffcd50c2ba9. Error: the floatingip d3d779e5-3ac6-44cc-bb90-7b65e22b96d0 has associated, please disassociate first.', u'code': u'400'}

Changed in tempest:
assignee: nobody → Zhenyu Zheng (zhengzhenyu)
description: updated
Changed in tempest:
status: New → In Progress
Revision history for this message
Ghanshyam Mann (ghanshyammann) wrote :

Actually this is not about creating 1 server in test class, it is like we create only 1 floating ip in validation resources and try to associate the same FIP to all instance requesting validation.

Validation resources are cleaned up at teardwonClass level.

I think we did not tested connect_method as floating ip and i am sure there will more cases where single class try to use same FIP in multiple servers.

For this test fail case, we can clean the server during teardown itself instead if waiting till teardwonClass.

But as general solution we need to think more on this. We can either create multiple FIP as per test class requirement or we cleanup validation resource during tearDown.

Changed in tempest:
status: In Progress → Confirmed
importance: Undecided → High
Changed in tempest:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to tempest (master)

Reviewed: https://review.openstack.org/460484
Committed: https://git.openstack.org/cgit/openstack/tempest/commit/?id=7a547df426a505d987dd53efb2f59d6ec2f63af8
Submitter: Jenkins
Branch: master

commit 7a547df426a505d987dd53efb2f59d6ec2f63af8
Author: Kevin_Zheng <email address hidden>
Date: Thu Apr 27 18:00:13 2017 +0800

    Fix volume attach tests failing when using FIP as ssh method

    When use floating as connect_method, tests:
    test_attach_detach_volume[id-52e9045a-e90d-4c0d-9087-79d657faffff]
    test_list_get_volume_attachments[id-7fa563fe-f0f7-43eb-9e22-a1ece036b513]
    will fail due to that they are under the same class, so when these tests
    setup, and using floating as connect_method only one floating IP was
    created.We first associated it to instance created at test1 and then we
    created another instance in test2 and tried to associate this IP again to
    the new server, since the IP was already associated to instance created in
    test1, error will happen when try to do this.

    This patch fix this by delete the servers after first test finished.

    Closes-Bug: #1686664

    Change-Id: Ie3afb31bd0d3245760f799b2256228159b328619

Changed in tempest:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/tempest 16.1.0

This issue was fixed in the openstack/tempest 16.1.0 release.

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.