This issue is also present in OSP7, heat is configured by TripleO to use Internal API network's IP instead of public one. VM can not therefore reach the heat metadata service as it is trying to execute from within:

$ SIGNAL_DATA='{"Status": "SUCCESS", "Reason": "SmokeServerNeutron created", "Data": "Application has completed configuration.", "UniqueId": "00000"}'
$ curl --fail -X PUT -H 'Content-Type:' --data-binary "$SIGNAL_DATA" 'http://172.17.1.11:8000/v1/waitcondition/arn%3Aopenstack%3Aheat%3A%3A376e5feb2d5b45c5b96161c252f5af73%3Astacks%2Fheat-786826425%2F6059118c-8235-4632-92c9-09b85d5ec21f%2Fresources%2FWaitHandleNeutron?Timestamp=2018-04-19T13%3A22%3A32Z&SignatureMethod=HmacSHA256&AWSAccessKeyId=8aa8a83621584d3b8cab4a9d12d2fdea&SignatureVersion=2&Signature=Vs3u9r0bApbRqNAZ3Fe202sApljLraj5hh6tMXFi3RI%3D'

and keystone catalog says:
Service: orchestration
+-------------+-------------------------------------------------------------+
|   Property  |                            Value                            |
+-------------+-------------------------------------------------------------+
|   adminURL  | http://172.17.1.11:8004/v1/376e5feb2d5b45c5b96161c252f5af73 |
|      id     |               80982cad82c845d298e5120592137eef              |
| internalURL | http://172.17.1.11:8004/v1/376e5feb2d5b45c5b96161c252f5af73 |
|  publicURL  |  http://10.0.0.101:8004/v1/376e5feb2d5b45c5b96161c252f5af73 |
|    region   |                          regionOne                          |
+-------------+-------------------------------------------------------------+

VM can not reach private IP and therefore test will also fail.

Workaround - use public IP range(VIP) - https://access.redhat.com/solutions/2868471 .

+++ This bug was initially created as a clone of Bug #1316072 +++

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

--- Additional comment from Red Hat Bugzilla Rules Engine on 2016-03-09 06:13:22 EST ---

Since this issue was entered in bugzilla without a release flag set, rhos-8.0? has been automatically added to ensure that it is properly evaluated for this release.

--- Additional comment from Mike Burns on 2016-04-07 17:14:44 EDT ---

This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.

--- Additional comment from John Skeoch on 2016-07-31 21:04:29 EDT ---

User acruz@redhat.com's account has been closed

--- Additional comment from Pavel Sedlák on 2017-03-09 09:50:55 EST ---

This is not bug in tempest, instead it's more of heat misconfiguration (by tripleo/puppets...)

--- Additional comment from Zane Bitter on 2017-03-09 11:12:39 EST ---

Do we think this is the same issue as bug 1425189?

--- Additional comment from Pavel Sedlák on 2017-03-23 13:00:23 EDT ---

Btw this is still failed on latest OSP11 puddle 2017-03-22.1,
 https://rhos-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/qe-phase2-11_director-rhel-7.3-virthost-3cont_1comp-ipv6-vlan-lvm-ssl/lastCompletedBuild/testReport/(root)/(empty)/setUpClass__tempest_api_orchestration_stacks_test_neutron_resources_NeutronResourcesTestJSON_/

afazekas pointed to this bug, but i'm now not sure if the ip was 127....,
or if it was failing with proper empty value in heat.conf (and so catalog used).

it may be case of second, will need to check that, as it happens only in combination of IPv6 and SSL, so it seems like different issue now.

--- Additional comment from Attila Fazekas on 2017-03-27 03:44:15 EDT ---

The packaged version of newton tempest skips this test because, the test
in tempest had issues that time, it worked before and after.

The error messages in the above test run also not helpful,
it is expected to be some Timeout exception, not some KeyError (fixed in upstream master).

The timeout reason in 11 can be something ipv6/ssl specific.

--- Additional comment from Pavel Sedlák on 2017-03-27 13:06:32 EDT ---

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.

--- Additional comment from Zane Bitter on 2017-07-17 09:41:38 EDT ---