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!

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.

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]}

@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?

@Steve -- OK to close and thanks again.

Ref comment #6 closing this as it's been determined as notabug.