Bug 1316072 - tempest.api.orchestration.stacks.test_neutron_resources.NeutronResourcesTestJSON failing due wrong heat_metadata and heat_waitcondition_server address
Status: CLOSED DUPLICATE of bug 1452677
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
8.0 (Liberty)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 12.0 (Pike)
Assigned To: Angus Thomas
Martin Kopec
: Automation, AutomationBlocker
Depends On:
  Show dependency treegraph
Reported: 2016-03-09 06:13 EST by Arx Cruz
Modified: 2017-07-17 09:41 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-07-17 09:41:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Arx Cruz 2016-03-09 06:13:19 EST
Description of problem:
 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 

Actual results:


Expected results:


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
crudini --set /etc/heat/heat.conf DEFAULT heat_waitcondition_server_url

systemctl restart openstack-heat-api openstack-heat-api-cloudwatch openstack-heat-api openstack-heat-engine
Comment 2 Mike Burns 2016-04-07 17:14:44 EDT
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.
Comment 8 Pavel Sedlák 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.
Comment 9 Zane Bitter 2017-07-17 09:41:38 EDT

*** This bug has been marked as a duplicate of bug 1452677 ***

Note You need to log in before you can comment on or make changes to this bug.