OS::Heat::ResourceGroup does not substitute index_var within intrinsics.

[Joe D'Andrea]

Presently, %index% can only be used in basic string substitutions, e.g., name: my_server_%index%, not within intrinsics. This happens because intrinsics are evaluated before the %index% replacement takes place, thus using it within any intrinsic will not result in a substitution.

It would be useful to support the use of %index% within intrinsics, prior to evaluation. This would afford a natural way to pass parameters to each member of a resource group.

Use Case: Create a set of VMs of the same type where IP address assignments are fixed in advance and must be passed in as parameters. The template may look something like this:

parameters:
   server_names:
     type: comma_delimited_list

resources:
  server_group:
     type: OS::Heat::ResourceGroup
     properties:
        count: 3
        resource_def:
           type: OS::Nova::Server
           name: { get_param: [ server_names, %index% ] }

This has been explored in the past (randallburt, Drago1) but it was rather tricky to do, if at all. Filing it here so that we can track it in case it can ever be resolved (and to see if others are interested in taking this one on).

As an interim workaround, kfox1111 suggests utilizing a nested stack as the resource, passing the index as a parameter.

[Steven Hardy (shardy)]

> As an interim workaround, kfox1111 suggests utilizing a nested stack as the resource, passing the index as a parameter.

Yes, we use this same approach in tripleo-heat-templates and it works fine as a workaround, enabling this cleaner syntax would certainly be worth further exploring though.

[Joe D'Andrea (jdandrea)]

Thanks, shardy! I had heard that this approach does *not* work in some use cases, specifically the ones that led to me filing this. It has been a while though, and I should have posted more info here. I appreciate the update. Stay tuned for more info ...

[Joe D'Andrea (jdandrea)]

Ah! Here's the problematic use case:

Edit the templates, adding one more name to the end of server_names and noting the increase in server count, then perform a stack update. This will result in every nested server being rebuilt, instead of just the additional server being created.

Thoughts?

[Joe D'Andrea (jdandrea)]

Hi! Pinging to see if anyone knows whether this may have since been fixed under a different bug ID.

[Mathias Ewald (mewald)]

Hi everyone! This is totally something we need, too! I know there is a workaround but leaving this hanging here since 2015 is not good ;) It would open so many possibilities and since Heat's default maximum nested stack depth is 5 adding more unnecessary nesting would certainly hurt at some point.

[Joe D'Andrea (jdandrea)]

Mathias, I would welcome the opportunity to revisit this one in tandem. Also, I'm not fond of the workaround as it is. (See my 2016-03-22 note.)

[Edward Hope-Morley (hopem)]

Hi Joe, are you actively working on a patch for this issue? I see you have been the assignee of this bug for quite a while but can't see any submission. If you are not working on a patch can you please un-assign yourself from this bug so that someone else can pick it up?

#As a side note, it's probably worth having a look at the comments in bug 1500475 where a patch was #submitted for adding, amongst other things, support for %index% to AutoScalingGroup and was #rejected on the grounds that it would cause some backwards incompatibilities.

As you point out the current implementation of %index% within an OS::Heat::ResourceGroup is only supported for property values and therefore not intrinsic_function parameters. If I understand correctly, what you want is to have a way to statically define instance configurations using parameter structures that can then be queried within a resource group loop so as not to have to explicitly define each and every instance outright.

I have had a go at doing this using a nested stack. See the following:

    http://pastebin.ubuntu.com/24053315/
    http://pastebin.ubuntu.com/24053312/

If I run heat stack-create mystack -f ./lp1470614_hot.yaml with the above I get two instances that have their respective configs applied. If I then up the count to 3 (and uncomment the extra configs) and do a stack-update, I get a third instance and by first two remain intact (contrary to your comment about this being a problem). Of course if, for example, modifying the count resulted in a change to what is applied in user_data then that would result in a new set of instances being deployed (with index counter reset) but that is by-design in Heat.

[Matt Pryor (mpryor)]

Has this been thought about any more? I would like to see it.

I am using the nested stacks approach, but am being bitten by the default nesting depth only being 5. I do not control the platform so cannot modify the nesting depth.

[Brahim BELLAOUI (braxuil)]

Hello.

Any news about this ?