tripleo

overcloud heat metadata URL's aren't configured

Bug #1653985 reported by Dan Prince
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo
Fix Released
High
Dan Prince
tripleo ocata-3 "ocata-3"

Bug Description

Trying to use heat configured via t-h-t templates in the undercloud and I discovered we aren't configuring any metadata URL's (does this mean nobody uses Heat software deployments in the overcloud)?

The fix should be to add a configuration for heat::engine::heat_metadata_server_url and heat::engine::heat_waitcondition_server_url in the heat-engine.yaml.

Dan Prince (dan-prince)
Changed in tripleo:
assignee: nobody → Dan Prince (dan-prince)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to tripleo-heat-templates (master)

Fix proposed to branch: master
Review: https://review.openstack.org/416573

Changed in tripleo:
status: New → In Progress
Emilien Macchi (emilienm)
Changed in tripleo:
milestone: none → ocata-3
importance: Undecided → High
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to tripleo-heat-templates (master)

Reviewed: https://review.openstack.org/416573
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=40cb3ab2ac647f2866d8b6ee52b963af05d1e336
Submitter: Jenkins
Branch: master

commit 40cb3ab2ac647f2866d8b6ee52b963af05d1e336
Author: Dan Prince <email address hidden>
Date: Wed Jan 4 09:41:02 2017 -0500

    Configure Heat engine metadata URL's

    Tried to use the heat-engine composable service in the Undercloud and I
    discovered that my software deployments (when spinning up an overcloud)
    weren't getting signals from my t-h-t configured undercloud heat.
    This patch resolves the issues by configuring the metadata URLs
    for Heat.

    Change-Id: I57c9e7010bfe4afc6e62fb4c3406716d11cdfa28
    Closes-bug: #1653985

Changed in tripleo:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/tripleo-heat-templates 6.0.0.0rc1

This issue was fixed in the openstack/tripleo-heat-templates 6.0.0.0rc1 release candidate.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to tripleo-heat-templates (stable/newton)

Fix proposed to branch: stable/newton
Review: https://review.openstack.org/439699

Revision history for this message
Steven Hardy (shardy) wrote :

I removed these settings because they should not be required - heat calculates the URL from the service catalog entries, so in theory these should only be needed when there's something weird about your networking (e.g you need to route tenant VM traffic to somewhere other than the public heat endpoints)

Revision history for this message
Graeme Gillies (graeme-r-gillies) wrote :

Hi,

I have a deployment of RDO Newton deployed by tripleo. It's using the latest overcloud packages from DLRN passed-ci.

I have confirmed in /etc/heat/heat.conf that none of the urls are set (they are there in comments but no actual values set).

However, when I deploy an instance, os-collect-config in the instance fails because the server url is http://127.0.0.1:8000/v1

So it seems that heat isn't in fact doing the right thing when left to its own devices.

I can provide additional information to assist debugging if needed.

Regards,

Graeme

Revision history for this message
Dan Prince (dan-prince) wrote :

Graeme, Per Steve's comments could you verify that your Keystone service catalog has the correct entries for the Heat endpoints?

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on tripleo-heat-templates (stable/newton)

Change abandoned by Steven Hardy (<email address hidden>) on branch: stable/newton
Review: https://review.openstack.org/439699
Reason: Abandoning as I don't think we need this, ref comment from Zane

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.