Heat SoftwareDeployments across provider resources

[Jim Minter]

As discussed with shardy and sbaker:

I think there are a couple of bugs in Icehouse around what happens when an OS::Nova::Server, OS::Heat::SoftwareConfig and OS::Heat::SoftwareDeployment objects are NOT all in the same template (i.e. using provider resources).

The following scenarios work for me:

1) OS::Nova::Server, OS::Heat::SoftwareConfig and OS::Heat::SoftwareDeployment all in the same base template
2) OS::Nova::Server, OS::Heat::SoftwareConfig and OS::Heat::SoftwareDeployment all in the same provider resource (let's call it Library::ServerAndConfig); provider resource referenced from the base template.

These two scenarios DON'T work for me:

3) OS::Nova::Server, OS::Heat::SoftwareConfig and OS::Heat::SoftwareDeployment A all in the same provider resource (let's call it Library::ServerAndConfig); provider resource referenced from the base template, and an /additional/ OS::Heat::SoftwareConfig and OS::Heat::SoftwareDeployment B instantiated in the base template, attached to the OS::Nova::Server.id returned by Library::ServerAndConfig. In this case, A gets provisioned and the stack hangs when it tries to do B.
4) OS::Nova::Server in one provider resource (let's call it Library::Server), OS::Heat::SoftwareConfig and OS::Heat::SoftwareDeployment in another provider resource (let's call it Library::Config), both referenced and attached from the base template. In this case the stack hangs when it tries to do the SoftwareDeployment.

In both cases 3 and 4, the problem is that the 'deployments' list returned to the instance when it polls the CFN API never grows to contain the relevant deployment objects, at which point it's game over.

I guess that there's some missing wiring in the CFN API backend for DescribeStackResource which could take note of all of the attached SoftwareDeployments across provider resources? If that's not the case, then I suspect the instance agent would need to issue a different type of API call which would presumably break compatibility with existing agents?

[Steve Baker (steve-stevebaker)]

I've just confirmed the following combination works as expected:
* config and deployment in a provider resource
* server and provider resource in the base template

Will try other combinations next

[Steve Baker (steve-stevebaker)]

I've confirmed the following works:
* config and deployment in one provider resource
* server in another provider resource
* base template configuring the server to the deployment

This looks like scenario 4 in the Bug Description

############ base template:
heat_template_version: 2013-05-23
parameters:
  key_name:
    type: string
    default: heat_key
  flavor:
    type: string
    default: m1.small
  image:
    type: string
    default: heat-functional-tests-image

resources:

  dep:
    type: software_config_deployment.yaml
    properties:
      server: {get_attr: [server, server_id]}

  the_sg:
    type: OS::Neutron::SecurityGroup
    properties:
      name: the_sg
      description: Ping and SSH
      rules:
      - protocol: icmp
      - protocol: tcp
        port_range_min: 22
        port_range_max: 22

  server:
    type: software_config_server.yaml
    properties:
      image: {get_param: image}
      flavor: {get_param: flavor}
      key_name: {get_param: key_name}
      security_group: {get_resource: the_sg}

outputs:
  res:
    value:
      result: {get_attr: [dep, result]}
      stdout: {get_attr: [dep, deploy_stdout]}
      stderr: {get_attr: [dep, deploy_stderr]}
      status_code: {get_attr: [dep, deploy_status_code]}
  server:
    value: {get_attr: [server, server_id]}

########### software_config_deployment.yaml
heat_template_version: 2013-05-23
parameters:
  server:
    type: string
  foo:
    default: foaye
    type: string
  bar:
    default: baba
    type: string

resources:
  cfg:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      inputs:
      - name: foo
      - name: bar
      outputs:
      - name: result
      config: {get_file: cfg1.sh}

  dep:
    type: OS::Heat::SoftwareDeployment
    properties:
      config:
        get_resource: cfg
      server: {get_param: server}
      input_values:
        foo: {get_param: foo}
        bar: {get_param: bar}

outputs:
  result:
    value: {get_attr: [dep, result]}

  deploy_stdout:
    value: {get_attr: [dep, deploy_stdout]}

  deploy_stderr:
    value: {get_attr: [dep, deploy_stderr]}

  deploy_status_code:
    value: {get_attr: [dep, deploy_status_code]}

########### software_config_server.yaml
heat_template_version: 2013-05-23
parameters:
  key_name:
    type: string
  flavor:
    type: string
  image:
    type: string
  security_group:
    type: string

resources:
  server:
    type: OS::Nova::Server
    properties:
      image: {get_param: image}
      flavor: {get_param: flavor}
      key_name: {get_param: key_name}
      security_groups:
      - {get_param: security_group}
      user_data_format: SOFTWARE_CONFIG

outputs:
  server_id:
    value: {get_resource: server}

########### cfg1.sh
#!/bin/sh
echo "Writing to /tmp/$bar"
echo $foo > /tmp/$bar
echo -n "The file /tmp/$bar contains `cat /tmp/$bar` for server \
$deploy_server_id during $deploy_action" > $heat_outputs_path.result
echo "Written to /tmp/$bar"
echo "Output to stderr" 1>&2

[Steve Baker (steve-stevebaker)]

OK, I'm getting to the bottom of this, I have issues when the server is in one provider resource and the the deployments are in another.

The issue I believe is that each provider resource is its own nested stack, and thus has its own stack_user_project_id. Building the deployments list for a server filters on stack_user_project_id (or tenant_id) which will differ across nested stacks.

The fix I think is for all nested stacks to share the same stack_user_project_id as the root stack, which means that create_stack_domain_project needs to be called up-front in Stack instead of deferred in StackUser handle_create

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/117058
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=177bb5c9d6d5985bf07c70d14c20cad8ca42f28c
Submitter: Jenkins
Branch: master

commit 177bb5c9d6d5985bf07c70d14c20cad8ca42f28c
Author: Steve Baker <email address hidden>
Date: Wed Aug 27 10:24:06 2014 +1200

    Common stack_user_project_id across nested stacks

    Currently the stack_user_project_id creation is deferred until
    a resource actually needs to create a user in it. This means
    for stacks with nested stacks there is a mixture of
    stack_user_project_id values across the stacks (including None).

    This causes issues when deployment resources are in one nested
    stack and server resources are in another since deployments
    are filtered by matching stack_user_project_id.

    This change creates and assigns stack_user_project_id during
    stack creation, and propagates this stack_user_project_id to
    any nested stacks so that all stacks in the tree share a single
    stack_user_project_id.

    Closes-Bug: #1343163
    Related-Blueprint: deployment-multiple-servers
    Change-Id: Ia161ec9989fe0e0792967d9e1e20361e67f46fe1