Bug 1313049 - [OSP 8.0 Bug]: Heat template yaml differences Beta-2 to Beta-7
[OSP 8.0 Bug]: Heat template yaml differences Beta-2 to Beta-7
Status: CLOSED NOTABUG
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
8.0 (Liberty)
All Linux
unspecified Severity high
: ---
: 8.0 (Liberty)
Assigned To: Angus Thomas
Arik Chernetsky
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-29 14:45 EST by Dave Cain
Modified: 2016-03-07 05:59 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-07 05:59:11 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dave Cain 2016-02-29 14:45:26 EST
Description: When using the rhel-osp-director (RHEL7.2) and associated heat templates, it appears that there's a difference in behavior with how these templates are interpreted in Beta2 vs. Beta7.  Take this template for example that I used successfully in Beta2:

/home/stack/templates/master.yaml
=================================
resource_registry:
  OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/extra/template1.yaml
  OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/extra/template2.yaml
  OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/extra/template3.yaml

However, with the OSP8-Beta7 code, this functionality only seems to apply only the last configured template listed in my master.yaml file, or template3.yaml.  Contrast that with Beta2 where all three templates would be applied to the overcloud configuration successfully.  Is this by design or a bug?

If this is the incorrect component for this bug, I apologize.  Can it be redirected please?  If you need log files, let me know and I'll provide them.

openstack-tripleo-image-elements-0.9.7-2.el7ost.noarch
openstack-tripleo-heat-templates-0.8.7-12.el7ost.noarch
openstack-tripleo-puppet-elements-0.0.2-1.el7ost.noarch
openstack-tripleo-common-0.1.1-1.el7ost.noarch
openstack-tripleo-heat-templates-kilo-0.8.7-12.el7ost.noarch
python-tripleoclient-0.1.1-2.el7ost.noarch
openstack-tripleo-0.0.7-1.el7ost.noarch
openstack-heat-common-5.0.1-1.el7ost.noarch
python-heatclient-0.8.0-1.el7ost.noarch
openstack-tripleo-heat-templates-0.8.7-12.el7ost.noarch
openstack-heat-api-cfn-5.0.1-1.el7ost.noarch
openstack-heat-templates-0-0.1.20151019.el7ost.noarch
openstack-heat-api-cloudwatch-5.0.1-1.el7ost.noarch
openstack-heat-api-5.0.1-1.el7ost.noarch
openstack-heat-engine-5.0.1-1.el7ost.noarch

Bugzilla dependencies (if any): N/A

Hardware dependencies (if any): N/A

Upstream information

Date it will be upstream: N/A

Version: RHEL-OSP8-Beta7

External links:


Severity (U/H/M/L): H

Business Priority: Must
Comment 2 Steven Hardy 2016-03-01 03:46:22 EST
Looking at this:

resource_registry:
  OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/extra/template1.yaml
  OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/extra/template2.yaml
  OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/extra/template3.yaml


I don't see how this can ever have worked, can you please double check this worked on 7.x, and also attach the output of openstack --debug overcloud deploy --templates -e master.yaml?

Basically this is a function of the yaml parsing, nothing really directly implemented by Heat or TripleO/OSPd and what you describe as working in Beta2 hasn't ever worked AFAIK, are you sure nothing else (e.g the templates) changed between your Beta2 and Beta7 tests?

For example, try pasting your yaml into http://yaml-online-parser.appspot.com or similar - you'll see that template3.yaml (or whatever comes last) always wins, this is just normal yaml mapping behavior when you have duplicate keys (it'd be great to throw a validation error when folks do this, but it's actually quite hard unless we override the default python yaml parser implementation).

What you need instead is a "wrapper" template similar to this:

https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/extraconfig/pre_deploy/controller/multiple.yaml

Then wrap your three deployment steps like (this is template1_2_3.yaml):

heat_template_version: 2014-10-16
description: 'Deploy extra stuff 1, 2 and 3'
parameters:
  server:
    type: string
resources:
  Config1:
    type: template1.yaml
    properties:
        server: {get_param: server}
  Config2:
    type: template2.yaml
    depends_on: Config1
    properties:
        server: {get_param: server}
  Config3:
    type: template3.yaml
    depends_on: Config2
    properties:
        server: {get_param: server}

Note the depends_on directives are optional, and can be used to serialize the application of each ExtraConfigPre template (or not, if you remove them).

Then create a resource registry like this:

resource_registry:
  OS::TripleO::ControllerExtraConfigPre: template1_2_3.yaml

In future, we'll be able to make use of the new OS::Heat::ResourceChain interface (which was implemented pretty much to satisfy this exact requirement), but at present (e.g with the version of heat we use in OSP8), the "wrapper template" approach is the only solution I can think of

http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::ResourceChain

Note that the described behaviour is consistent with our current examples & docs:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/7/html/Director_Installation_and_Usage/sect-Configuring_before_Overcloud_Creation.html

"You can only register these resources to only one Heat template each. Subsequent usage overrides the Heat template to use per resource. "

Please double check, and let me know if you can find any other clues which indicate a director bug vs a change in your ExtraConfigPre templates, thanks!
Comment 3 Steven Hardy 2016-03-01 13:23:44 EST
Discussion on IRC indicates my example above is incomplete, because we don't include a deploy_stdout, should be something like:

heat_template_version: 2014-10-16
description: 'Deploy extra stuff 1, 2 and 3'
parameters:
  server:
    type: string
resources:
  Config1:
    type: template1.yaml
    properties:
        server: {get_param: server}
  Config2:
    type: template2.yaml
    depends_on: Config1
    properties:
        server: {get_param: server}
  Config3:
    type: template3.yaml
    depends_on: Config2
    properties:
        server: {get_param: server}
outputs:
  deploy_stdout:
    value:
      list_join:
      - ','
      - {get_attr: [Config1, deploy_stdout]}
      - {get_attr: [Config2, deploy_stdout]}
      - {get_attr: [Config3, deploy_stdout]}

This is consumed here:
https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/controller.yaml#L1716

We'll join together e.g:

https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/extraconfig/pre_deploy/controller/cinder-netapp.yaml#L146

Probably just setting the value to a dummy string would also be sufficient, given that in recent OSPd versions we always run puppet on update.
Comment 4 Dave Cain 2016-03-02 00:11:36 EST
My thanks to Steve Hardy for helping me with this in Beta7.  I'm now able to have two different resources configured in my respective environment with one resource_registry of OS::TripleO::ControllerExtraConfigPre using the "wrapper" template described above.  I'm not sure of the etiquette here, but this Bug should probably be closed as my problem appears to be resolved.

For reference, this is the deployment command I used to deploy my Overcloud:
========================
openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /home/stack/templates/network-environment.yaml -e /home/stack/templates/master.yaml --control-scale 1 --compute-scale 1 --control-flavor control --compute-flavor compute --ntp-server time.netapp.com --neutron-network-type vxlan --neutron-tunnel-types vxlan
========================

Here's master.yaml, which is what gets passed to the overcloud deployment script:
========================
resource_registry:
  OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/wrapper.yaml

parameter_defaults:
  CinderEnableNetappBackend: true
  GlanceNetappCopyOffloadMount: '192.168.67.1:/glance'
========================

Here's wrapper.yaml which ties together two different resources as shown:
========================
heat_template_version: 2014-10-16
description: 'Stuff'
parameters:
  server:
    type: string
resources:
  Config1:
    type: /home/stack/templates/template1.yaml
    properties:
        server: {get_param: server}
  Config2:
    type: /home/stack/templates/template2.yaml
    properties:
        server: {get_param: server}
outputs:
  deploy_stdout:
    value:
      list_join:
      - ''
      - - {get_attr: [Config1, deploy_stdout]}
        - {get_attr: [Config2, deploy_stdout]}
========================
        
I had to make a modification in the wrapper template described in comment 3 as the syntax below didn't work for me:

(In reply to Steven Hardy from comment #3)

> outputs:
>   deploy_stdout:
>     value:
>       list_join:
>       - ','
>       - {get_attr: [Config1, deploy_stdout]}
>       - {get_attr: [Config2, deploy_stdout]}
>       - {get_attr: [Config3, deploy_stdout]}
Comment 5 Steven Hardy 2016-03-02 08:59:22 EST
@Dave - thanks for the confirmation, sorry about the list_join syntax mistake!

Can we close this now, or do you thing there is still a bug to resolve?
Comment 6 Dave Cain 2016-03-02 09:11:24 EST
@Steve -- OK to close and thanks again.
Comment 7 Steven Hardy 2016-03-07 05:59:11 EST
Ref comment #6 closing this as it's been determined as notabug.

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