Migration and resize tests from tempest.scenario.test_minbw_allocation_placement.MinBwAllocationPlacementTest failing in neutron-tempest-dvr-ha-multinode-full
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Invalid
|
Undecided
|
Unassigned | ||
neutron |
Fix Released
|
Critical
|
Unassigned | ||
tempest |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
We saw it mostly in stable/train branch. Cold migration and resize tests from tempest.
Traceback (most recent call last):
File "/opt/stack/
return f(*func_args, **func_kwargs)
File "/opt/stack/
self.
File "/opt/stack/
return self.action(
File "/opt/stack/
post_body)
File "/opt/stack/
return self.request(
File "/opt/stack/
method, url, extra_headers, headers, body, chunked)
File "/opt/stack/
self.
File "/opt/stack/
raise exceptions.
tempest.
Details: {'code': 400, 'message': 'No valid host was found. No valid host found for cold migrate'}
Logstash query which can be useful to find same issues: http://
Changed in neutron: | |
status: | New → Fix Released |
Looking through the example failure from above I see the followings:
1) there are 3 compute nodes exist in the job. One on the main devstack node (controller) and one on each of the two devstack subnodes (compute1, compute2).
2) Already during the creation of the instance failed in the report placement returned one compute node that has the enough resources, the node on the controller. So the instance was booted there
3) Then later during the migration placement returned the same single compute, but that was ignored by the scheduler as it is the source node of the migration
4) Looking into the 3 q-agt logs it is clear why placement only returned the compute node on the controller host. It is only the q-agt on the controller host that has bandwidth inventory configured[1], the agents on the other compute hosts[2][3] has no bandwidth inventory so they cannot be used for the instance.
So I see two possible ways forward:
A) modify the job config to have bandwidth inventory on the subnode computes
B) modify the tempest tests to not only check if multiple computes are available[4] before executing this test, but also check if at least two computes has bandwidth inventory.
[1]https:/ /a574f9c0fd4ca9 2b7603- 2045be852d43868 eb95da6cc3429b4 0d.ssl. cf2.rackcdn. com/777334/ 2/check/ neutron- tempest- dvr-ha- multinode- full/44d0207/ controller/ logs/etc/ neutron/ plugins/ ml2/ml2_ conf.ini /a574f9c0fd4ca9 2b7603- 2045be852d43868 eb95da6cc3429b4 0d.ssl. cf2.rackcdn. com/777334/ 2/check/ neutron- tempest- dvr-ha- multinode- full/44d0207/ compute1/ logs/etc/ neutron/ plugins/ ml2/ml2_ conf.ini /a574f9c0fd4ca9 2b7603- 2045be852d43868 eb95da6cc3429b4 0d.ssl. cf2.rackcdn. com/777334/ 2/check/ neutron- tempest- dvr-ha- multinode- full/44d0207/ compute2/ logs/etc/ neutron/ plugins/ ml2/ml2_ conf.ini /github. com/openstack/ tempest/ blob/ccf56b5ca2 78fd083946137a5 c36cdd8ba2f230d /tempest/ scenario/ test_minbw_ allocation_ placement. py#L242
[2] https:/
[3] https:/
[4] https:/