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 parameter_defaults: CinderEnablaeNfsBackend: true CinderNfsServers: 172.31.17.4:/cinder 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: CinderNfsMountOptions: "''" 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 hiera files? Version-Release number of selected component (if applicable): openstack-tripleo-heat-templates-0.8.6-121.el7ost
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 [1], 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 [2]. [1] https://review.openstack.org/#/c/188772/ [2] https://review.openstack.org/#/c/245225/
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.