Nested stacks currently (Heat Template Version 2014-10-16) support the following data types for nested stacks' parameters (or generally stack parameters for that matter):
string, number, boolean, comma_delimited_list, json
The latter two look like they could theoretically be used for more complex data structures, such as:
* The `networks` attribute of OS::Nova::Server (a list of maps)
* The `allocation_pools` attribute of OS::Neutron::Subnet (a list of maps)
Hence I tried creating a stack that invoked the attached nested stack as follows:
network:
type: networks-wrapper.yaml
properties:
cidr: 10.10.10.0/24
allocation_pools:
- {start: 10.10.10.10, end: 10.10.10.150}
name:
list_join:
- '_'
- [ heat, { get_param: 'OS::stack_name' } ]
This resulted in a CREATE_FAILED status with the following stack_status_reason:
Resource CREATE failed: StackValidationFailed: Property
error : subnet: allocation_pools Property error :
allocation_pools: 0 ".member.0.start=10.10.10.10" is
not a map
Note, that it seems to have passed template validation (if the parameter type for the allocation_pools parameter in networks-wrapper.yaml is `json`, for instance, validation simply fails). Apparently the data structure was not recognized as such. Instead, some kind of serialized representation was passed to OS::Neutron::Subnet, which tripped it up.
Another observation: The problem seems to lie with parameters actually passed to the template. If the parameter is not being passed, causing the default value for allocation_pools in networks-wrapper.yaml to be used, the stack will be created without any problems.
This is similar to an issue observed by dprince working on tripleo-
I'm looking into a way to fix that, so I'll take this & see if a common solution is possible.