Open Stack

On Thu, Dec 7, 2017 at 7:22 AM, Cédric Jeanneret
<cedric.jeanneret at camptocamp.com> wrote:
> Hello,
>
> While trying to add some unit tests for some resources in the
> puppet-tripleo repository, I stumbled on a not-so-nice case: the
> tripleo::firewall::service_rules definition.
>
> In there, a resource is dynamically taken from hiera, using the
> following key structure:
> tripleo.<name>.firewall_rules
>
> Although this seems to work properly in the tripleo deploy process, it
> just doesn't work at all for a unit test.
>
> After some more digging, it appears the "dot" (".") in YAML is a
> reserved char for hashes. In the puppet world, we usually use the double
> semi-colon, aka "::" as a separator.
>
> Sooo… I'm wondering what's the history behind that non-puppet-standard
> choice of "dot" separator, and what would be required in order to move
> to a more standard syntax for that kind of resources.

dprince may be the best person to answer as IIRC he implemented this originally.

However I suspect the choice of "." was deliberate to differentiate
from :: which implies the hiera values are consumed by puppet class
interfaces, vs parsed inside the class.

Can you work around the yaml issue by using quotes to force the
"tripleo.foo.firewall" to be a string?

We don't seem to require that for any templates in
tripleo-heat-templates though, is that just because the yaml key gets
cast to a string by hiera?

> I've checked the puppet-tripleo repository, and apparently only two
> resources are using that kind of syntax:
> - tripleo::firewall::service_rules (already widely present in the
> tripleo-heat-templates)
> - tripleo::haproxy::service_endpoints
> (at least, those are the only resources using a "$underscore_name" variable)
>
> Currently, if anyone wants to change something close to those two
> resources, it won't be tested against regressions, and it's a really bad
> situation. Especially since it might break central services (closing all
> firewall ports isn't good, for example, or dropping an haproxy endpoint
> by mistake)… Unit tests are needed, especially in such a huge piece of
> software ;).

Yeah I think we need to know more about the reasons this syntax won't
work for unit tests, we could conceivably change it, but as you say
it's widely used for firewall rules, and could potentially break any
out of tree service templates that exist, so we'd have to follow a
deprecation process to change the interface.

Thanks,

Steve