Red Hat Bugzilla – Bug 1313220
Empty parameters in tripleo heat template not translated to empty hiera values
Last modified: 2016-10-09 23:51:39 EDT
Description of problem:
I've noticed that that an parameter with an empty value in our tripleo
heat templates will not translate into an empty hiera value. It just
get dropped. With a failed deployment/update as result.
Specifically, I meant to deploy an OSP with an cinder NFS backend using
OSP-d. So setting
Right? Not so easy, deploying this fails with puppet complaining that
cinder_nfs_mount_options is not available in any Hiera data file.
Looking in overcloud-without-mergepy.yaml, CinderNfsMountOptions is
defined there with a default value of ''
So solution was to override this default, the following did the trick:
I'm guessing this is a generic problem,
that parameters with empty values get dropped from hiera. So what would
be the best way of solving this? Should we change the syntax of how we
specify empty default values? Or is there a better way of creating the
Version-Release number of selected component (if applicable):
Yes, there is broken data type handling between Heat and Hiera (single-line strings are passed literally to hiera, unquoted, so e.g. a string "[1,2]" actually gets converted into an array, empty string gets converted into null value, and if you need empty string, you need to work around that by nesting the quotes "''", which will get unwrapped into hiera as '' (empty string), as you wrote above.
It's something that bites us from time to time, i fixed a part of it some time ago but not all , as unfortunately too much depends on the literal passing behavior now (the string->array conversion mentioned above, for example). I think it would be worth investigating if we can fix it fully, but it's an XXL task with uncertain outcome and needs to be prioritized/scheduled as such.
However, specifically for CinderNfsMountOptions there's a fix merged and backported into stable/liberty, which allows null value to be used, so the "''" workaround isn't necessary .
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.