Description of problem: heat metadata urls are set to 127.0.0.1 in the defaults in /usr/share/heat/heat-dist.conf: heat_metadata_server_url = http://127.0.0.1:8000 heat_waitcondition_server_url = http://127.0.0.1:8000/v1/waitcondition heat_watch_server_url =http://127.0.0.1:8003 Recently there was a BZ around those values being set to 127.0.0.1 via Puppet #1395139 this has been fixed by removing those defaults from the heat-puppet modules. And now those values are no longer defined in /etc/heat/heat.conf. This means that they fall back to the values from /usr/share/heat/heat-dist.conf from the openstack-heat-commons package, which still have those values set to 127.0.0.1. A complete fix of the problem would require to remove those values from /usr/share/heat/heat-dist.conf as well, and then Heat would finally fall back to the values provided by Keystone. Alternatively it should be explicitely set to the correct heat_cfn endpoint. Version-Release number of selected component (if applicable): puppet-heat-9.5.0-1.el7ost.noarch openstack-heat-api-cfn-7.0.2-1.el7ost.noarch python-heat-agent-0-0.11.1e6015dgit.el7ost.noarch openstack-heat-api-7.0.2-1.el7ost.noarch python-heat-agent-puppet-0-0.11.1e6015dgit.el7ost.noarch python-heatclient-1.5.0-1.el7ost.noarch openstack-heat-api-cloudwatch-7.0.2-1.el7ost.noarch openstack-heat-common-7.0.2-1.el7ost.noarch openstack-heat-engine-7.0.2-1.el7ost.noarch heat-cfntools-1.3.0-2.el7ost.noarch How reproducible: Always Steps to Reproduce: 1. Install OSP10 2. Launch a Heat stack containing with a Nova instance and using a SoftwareDeployment and SOFTWARE_CONFIG 3. Check that /var/lib/heat-cfntools/cfn-init-data Actual results: "metadata_url" is set to 127.0.0.1 Expected results: "metadata_url" is set to the Public heat_cfn endpoint. Additional info:
I think this is the same issue as bug 1425189. It definitely sounds to me like heat-dist.conf is wrong, because IIUC Heat can now do the Right Thing based on the keystone catalog as long as nothing is explicitly specified in a config file.
(In reply to Zane Bitter from comment #1) > I think this is the same issue as bug 1425189. That's my understanding. But the fix from 1425189 only partially solved the issue, i.e. 1425189 removed the wrong setting from /etc/heat/heat.conf, but it's still in /usr/share/heat/heat-dist.conf
(In reply to David Gurtner from comment #2) > (In reply to Zane Bitter from comment #1) > > I think this is the same issue as bug 1425189. > > That's my understanding. But the fix from 1425189 only partially solved the > issue, i.e. 1425189 removed the wrong setting from /etc/heat/heat.conf, but > it's still in /usr/share/heat/heat-dist.conf Sorry, got confused between 1425189 and 1395139, please disregard the above.
The suggestion in bug 1425189 was effectively that it was already solved by bug 1395139, so there should be no need to set the addresses explicitly (as in https://review.openstack.org/#/c/439699/). This in my mind confirms that that is not the case, but the correct fix is to change heat-dist.conf, not to set the addresses explicitly in t-h-t.
Posted a fix to RDO: https://review.rdoproject.org/r/#/c/6877/ I'll backport downstream once it has been reviewed.
*** Bug 1425189 has been marked as a duplicate of this bug. ***
We realized that upstream github templates were used for the job on downstream product, something that is unsupported, bugzilla can be closed
(In reply to Eduard Barrera from comment #9) > We realized that upstream github templates were used for the job on > downstream product, something that is unsupported, bugzilla can be closed I opened the above bug in relation to a different environment from the one Eduard was working on. The bug itself is still valid and shouldn't be closed. Thanks, David
*** Bug 1316072 has been marked as a duplicate of this bug. ***
changes applied not metadata URL on: openstack-heat-api-cfn-7.0.5-1.el7ost.noarch openstack-heat-common-7.0.5-1.el7ost.noarch openstack-heat-api-7.0.5-1.el7ost.noarch openstack-heat-engine-7.0.5-1.el7ost.noarch openstack-heat-templates-0-0.12.1e6015dgit.el7ost.noarch [
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2655