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):
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.
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: wrapper. yaml n_pools:
type: networks-
properties:
cidr: 10.10.10.0/24
allocatio
- {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:
| stack_status_reason | Resource CREATE failed: StackValidation Failed: Property | 0.start= 10.10.10. 10" is |
| | error : subnet: allocation_pools Property error : |
| | allocation_pools: 0 ".member.
| | not a map |
Note, that it seems to have passed template validation (if the parameter type wrapper. yaml is `json`, for
for the allocation_pools parameter in networks-
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 wrapper. yaml to be used, the stack will
to the template. If the parameter is not being passed, causing the default
value for allocation_pools in networks-
be created without any problems.