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
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.
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.
*** This bug has been marked as a duplicate of bug 1452677 ***