Description of problem:
tempest.api.orchestration.stacks.test_neutron_resources.NeutronResourcesTestJSON
is failing in ospd virtualized, because the ip address set in /etc/heat/heat.conf isn't reachable by the vm. It has to be the public_virtual_ip
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1. Install OSP-D
2. Run tempest
3.
Actual results:
tempest.api.orchestration.stacks.test_neutron_resources.NeutronResourcesTestJSON
Fails
Expected results:
tempest.api.orchestration.stacks.test_neutron_resources.NeutronResourcesTestJSON
Pass
Additional info:
Changing the /etc/heat/heat.conf ip address to the public_virtual_ip and restart the services works:
crudini --set /etc/heat/heat.conf DEFAULT heat_metadata_server+url http://192.168.1.101:8000
crudini --set /etc/heat/heat.conf DEFAULT heat_waitcondition_server_url http://192.168.1.101:8000/v1/waitcondition
systemctl restart openstack-heat-api openstack-heat-api-cloudwatch openstack-heat-api openstack-heat-engine
In our case, it fails in IPv6 deployments (as the tenant network and vm used in test, has IPv4, and cannot reach IPv6 address).
Though, unlike mentioned in bug 1425189 linked commits, the url's in heat.conf are set:
> #heat_metadata_server_url = <None>
> heat_metadata_server_url = http://[2620:52:0:13b8:5054:ff:fe3e:9]:8000
> #heat_waitcondition_server_url = <None>
> heat_waitcondition_server_url = http://[2620:52:0:13b8:5054:ff:fe3e:9]:8000/v1/waitcondition
> #heat_watch_server_url =
So in our case it's different bug then this (in testcase, or our possibly setup/...).
And this one could be solved by that bug 1425189 (at least for 11).
Though unlike upstream reviews linked from bug 1425189, in our case the url are set (and so not defaulting to values from keystone catalog), which may be other issue.