This time the exception was this:
tempest.lib.exceptions.Conflict: Conflict with state of target resource
Details: {'type': 'PortInUse', 'message': 'Unable to complete operation on port 62105403-77f1-4f28-a2d8-54e64048def7 for network b528d78b-5f74-4b74-8a2e-6cb71c06ec79. Port already has an attached device 985e5be8-0e5f-48e6-abb7-59b961828205.', 'detail': ''}
Perhaps not related but another failure for test_trunk_ subport_ lifecycle: /review. opendev. org/c/openstack /neutron/ +/809268 /dd25c8fff5148b ff9a3d- e4098ecd70541cc fec6de5edaad12e 3e.ssl. cf5.rackcdn. com/809268/ 1/check/ neutron- tempest- plugin- scenario- openvswitch/ aafed35/ testr_results. html
https:/
https:/
This time the exception was this: lib.exceptions. Conflict: Conflict with state of target resource 77f1-4f28- a2d8-54e64048de f7 for network b528d78b- 5f74-4b74- 8a2e-6cb71c06ec 79. Port already has an attached device 985e5be8- 0e5f-48e6- abb7-59b9618282 05.', 'detail': ''}
tempest.
Details: {'type': 'PortInUse', 'message': 'Unable to complete operation on port 62105403-
So it seems that the after the suports are removed from the trunk of VM2 (see https:/ /opendev. org/openstack/ neutron- tempest- plugin/ src/branch/ master/ neutron_ tempest_ plugin/ scenario/ test_trunk. py#L266 ) and the ports go down, the suports can't be added to the trunk of vm2 as the subport still has an attached device id