On 20/03/18 04:53, Sashan Govender wrote:
> Hi
>
> Is there a way to check heat templates. At the moment I run one and it
> errors at runtime when, for example an something expects a string but
> gets a list. For example in this case of an OS::Heat::SoftwareConfig
> resource, the config attribute below expects a string, which is why
> str_replace works
Note that str_replace doesn't have to return a string (it returns
whatever type its 'template' is), but yeah in this case it does so it works.
> some_resource:
> type: OS::Heat::SoftwareConfig
> properties:
> config:
> str_replace:
> params:
> $repstr$:
> list_join: ['-', [ {get_param: cluster_name}, 'xyz']]
> template: |
> #!/bin/bash
> echo $repstr$ >> /etc/somefile
>
> According to this
> https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Heat::SoftwareConfig
>
> the config property expects a string.
Yep. OS::Heat::StructuredConfig is what you want if you want to pass
lists or maps.
> If I replace str_replace with something that generates a list (e.g.
> repeat) it fails at runtime. Is there a way to type check this? I tried
> 'heat template-validate' but it didn't do what I expected...
template-validate unfortunately doesn't validate property _values_ at
all, for historical reasons (in CloudFormation the parameter values
don't get passed to template-validate, although in the OpenStack API
they optionally can be since Icehouse). I think this is something we
should look at improving. I filed a bug report:
https://bugs.launchpad.net/heat/+bug/1757163
An additional subtlety is that because the output of intrinsic functions
can't be known ahead of time in many cases (e.g. get_resource,
get_attr), we still have to defer some checking to resource
create/update time when all of the data is available. We do have some
thoughts around how to improve this in the future, but it's a fairly
major development effort.
cheers,
Zane.