software config/deploy return signal error

Bug #1817528 reported by Tomas Holmberg on 2019-02-25
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

software config/deploy return signal error

Brief Description
The return signal for a software config/deploy is sent using the external address instead of the public. The result is that the signal from guest to StarlingX will never be received.


Steps to Reproduce
Run the following stack

heat_template_version: 2013-05-23

description: >
  Minimal SoftwareDeployment
    type: string
    default: medium_flav
    type: string
    default: ubuntu2
    default: net_a
    type: string
    type: string
    default: admin

    type: OS::Nova::KeyPair
      name: my_key3
      save_private_key: True
      user: {get_param: user}

    type: OS::Neutron::SecurityGroup
        - protocol: tcp
          port_range_min: 1
          port_range_max: 65535
        - protocol: icmp

    type: OS::Neutron::Port
      network: {get_param: network}
        - default
        - { get_resource: my_security_group }

    type: OS::Heat::SoftwareConfig
        - name: message
          default: 'NONE'
        - name: file_content
      group: script
      config: |
        #!/bin/sh -x
        echo "PNYXTER EKO"
        echo "${message}" > /tmp/pnyxter
        cat /tmp/pnyxter > ${heat_outputs_path}.file_content

    type: OS::Heat::SoftwareDeployment
      signal_transport: CFN_SIGNAL
      config: {get_resource: my_software_config}
      server: {get_resource: my_server}
        message: 'pnyxter mestxt'

    type: OS::Nova::Server
      name: th3
      image: {get_param: image}
      flavor: {get_param: flavor}
      key_name: {get_resource: my_key}
      user_data_format: SOFTWARE_CONFIG
        - port: {get_resource: my_port}

      get_attr: [my_software_deployment, file_content]
      get_attr: [my_software_deployment, deploy_stdout]
      get_attr: [my_software_deployment, deploy_stderr]
      get_attr: [my_software_deployment, deploy_status_code]
      get_attr: [my_key, private_key]
      get_attr: [my_key, public_key]


Expected Behavior
The server resource should have lock like this:
          "type": "String",
          "name": "deploy_signal_id",
          "value": "http://<public_addr>:8000/v1/signal/....",
          "description": "ID of signal to use for signaling output values"

Actual Behavior
The server resource should have lock like this:
          "type": "String",
          "name": "deploy_signal_id",
          "value": "http://<internal_addr>:8000/v1/signal/....",
          "description": "ID of signal to use for signaling output values"

System Configuration
One node

Branch/Pull Time/Commit
ISO from

Add the following line to to /usr/lib/python2.7/site-packages/heat/engine/resources/

--- /usr/lib/python2.7/site-packages/heat/engine/resources/signal_responder.py_org 2019-02-25 09:50:30.061517795 +0000
+++ /usr/lib/python2.7/site-packages/heat/engine/resources/ 2019-02-25 09:50:44.533517917 +0000
@@ -158,6 +158,7 @@
+ signal_url = config_url.replace('/waitcondition', signal_type)
             heat_client_plugin = self.stack.clients.client_plugin('heat')
             endpoint = heat_client_plugin.get_heat_cfn_url()

Ghada Khalil (gkhalil) wrote :

From Al Bailey:
The config url is set to: (public endpoint in my lab)

This is translated by the heat code to the internal url:

The WRS code that does that is here:

This was done to fix CGTS-3907

If change that method to be similar to what upstream does, it should work for this customer as long as they are not using https or IPv6

This is the standard upstream code which does our alterations.

If you want to demonstrate that this fix works in this scenario, this is the file that needs to be changed:

find these lines (around line 155)
 signal_url = "%s://%s:%s%s%s" % ("http",

and add the following one line right below it (which basically sets the variable to what upstream is doing)
signal_url = config_url.replace('/waitcondition', signal_type)

Note: This will not work with IPv6 and https
This will however work for the tests highlighted here

After you make this change (and make sure you backup the original file), you can restart heat engine:

sudo sm-restart service heat-engine

then you should be able to create their stack.
Note: the stack uses a keypair, which may or may not need to be manually cleaned up

Changed in starlingx:
assignee: nobody → Al Bailey (albailey1974)
Ghada Khalil (gkhalil) wrote :

As already confirmed by the reporter, the suggested code change addresses the issue. However, this is just a workaround which is not suitable for submission in the StarlingX 2018.10 release as it would result in IPv6 and https issues with heat.

We expect this to work in newer releases of StarlingX as the code will be based on Stein and will align with the upstream behavior.

Our recommendation is to live with the workaround for now until StarlingX is rebased on Stein.

Tomas, please let us know if you have concerns with this approach.

tags: added: stx.distro.openstack
Changed in starlingx:
importance: Undecided → High
Tomas Holmberg (wr-tholmber) wrote :

I do not have a personal opinion in this. You know better which other parts of the code which will not work. However it would be nice with some kind of warning.

Ghada Khalil (gkhalil) wrote :

Agreed to live with the workaround for stx.2018.10. We will retest in stx.2019.05 after moving to Stein to ensure this is still working. Then we'll close the bug at that time.

tags: added: stx.2019.05
Changed in starlingx:
status: New → Triaged
Bruce Jones (brucej) wrote :

We have re-based to Stein. Need to retest this bug and make sure it has been addressed.

Frank Miller (sensfan22) wrote :

Lowered priority to medium as a workaround exists.

Changed in starlingx:
importance: High → Medium
Ken Young (kenyis) on 2019-04-05
tags: added: stx.2.0
removed: stx.2019.05
Bruce Jones (brucej) wrote :

This defect needs to be retested since we rebased to upstream Stein and this issue may no longer exist.

tags: added: stx.retestneeded
Al Bailey (albailey1974) wrote :

In my retest env (heat running in containerized openstack)
  m1.tiny as the flavor.
  cirros qcow image rather than ubuntu
  Used the tenant networking setup from the containers wiki to setup a network and selected: public-net0

The stack create seems to hang
I am not getting a signal error. Its just hanging


I don't know enough about software deployment and signalling to know if my problem is because of my cirros image, or if it is due to a config issue. I don't see any sign of deploy_signal_id anywhere in the logs or the CLI queries.

Jan Borren (lmfjbor) wrote :

Possibly the Cirros image as the image that you use need to contain the agent toolchain os-collect-config, os-refresh-config and os-apply-config.

Example for adding this agent toolchain to a ubuntu cloud image:

# Details:

git clone
git clone

pip install --upgrade pip
pip install git+

export ELEMENTS_PATH=tripleo-image-elements/elements:heat-agents/
export BASE_ELEMENTS="ubuntu"
export AGENT_ELEMENTS="os-collect-config os-refresh-config os-apply-config"
export DEPLOYMENT_BASE_ELEMENTS="heat-config heat-config-script"
export IMAGE_NAME=ubuntu-software-config

openstack image create --disk-format qcow2 --container-format bare $IMAGE_NAME < $IMAGE_NAME.qcow2

yong hu (yhu6) wrote :

in WW30/31, we need to try this recipe described above.

yong hu (yhu6) wrote :

@Bill to ask help from Hao (FiberHome).

Bill Zvonar (billzvonar) on 2019-07-16
Changed in starlingx:
assignee: Al Bailey (albailey1974) → wanghao (wanghao749)
zhangyifan (zhangyifan) wrote :

Can you provide the ubuntu image for me?

yong hu (yhu6) wrote :

@zhangyifan, you might have several ways to get the guest image:
1. for ubuntu cloud image, you can download one:
2. get the image from @Jan or @Bill.
3. use cirros

Ghada Khalil (gkhalil) wrote :

As per agreement with the community, moving all unresolved medium priority bugs from stx.2.0 to stx.3.0

tags: added: stx.3.0
removed: stx.2.0
yong hu (yhu6) wrote :

@wanghao, could you have someone in your team working on this LP?

We might need a follow-up or decision on this one for stx.3.0.

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

Other bug subscribers