Tempest tests cannot run in parallel

Bug #1660366 reported by Bernard Cafarelli on 2017-01-30
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
networking-sfc
Undecided
maestropandy

Bug Description

Currently, tempest tests need to be run sequentially, or else they fail with bugs like bug #1655618

Tests work for now with this workaround:
https://git.openstack.org/cgit/openstack/networking-sfc/commit/?id=d31008bc0c8a829995a310b64519d125f6c055c1

But they should be updated to allow parallel runs (http://docs.openstack.org/developer/tempest/HACKING.html#parallel-test-execution)

One of the identified reasons is flow classifier parameters are identical between tests, so this generates conflicts like:
Details: {u'type': u'PortChainFlowClassifierInConflict', u'detail': u'', u'message': u'Flow Classifier fdce19cc-bc4c-432d-b4d0-bc5e1fb795a5 conflicts with Flow Classifier a5db4038-e49f-4c7e-9e5b-13b2beee3251 in port chain 07bd1ba0-202e-4551-b4ee-971f4f3c4ec2.'}

But there may be more problems to fix before having parallel-capable tempest tests

description: updated
Bernard Cafarelli (bcafarel) wrote :

To expend on the PortChainFlowClassifierInConflict issue:
tests create a flow classifier with parameters logical source port, source ip prefix, destination ip prefix

The logical source port is ignored for the conflict check, so if the server IP addresses are identical it will conflict. The flow classifiers should be different for each test (force separate IP addresses, add extra parameters, ...)

Changed in networking-sfc:
assignee: nobody → maestropandy (maestropandy)
Bernard Cafarelli (bcafarel) wrote :

Another reason to solve this and remove the workaround: by doing separate runs we lose the artifacts of the previous run, see Armando's comments at https://review.openstack.org/#/c/446743

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

Other bug subscribers