https://www.puppet.com/community logo
Join Slack
Powered by
This message was deleted.
# office-hours
s
This message was deleted.
j
The reason I ask is we've uncovered some not well-defined behavior if the hierarchy is defined using top-level variables, eg like facts or node parameters. Puppet loads 
hiera.yaml
and attempts to create the various data providers. But since this happens outside of any compilation, it will raise (when 
strict/strict_variables
is set to error)
b
yeah I assumed that as you typed it. I support a few puppet setups. some use topscope variables in hiera.yaml, some have strict/strict_variables enabled. but there is zero overlap between those two groups
and I think it would be really helpful to have strict/strict_variables enabled by default in Puppet. I think we even talked about it and raised an issue? but I didn't consider hiera.yaml back then
all topscope variables I have in hiera.yaml come from PE node groups
j
Yep we made the switch, but are running into issues https://tickets.puppetlabs.com/browse/PUP-11751
b
interesting
I always assumed those settings only effect Puppet DSL, not hiera.yaml
j
Yeah same until recently
y
I saw this behaviour with strict variables while ago in my homelab.. so I relaxed it :(
I found no workaround at that time
s
I had this same issue, but I was able to scope the top level vars into facts
Copy code
paths:
      - "nodes/%{trusted.certname}.yaml"
      - "role/%{facts.puppet_role}.yaml"
I was very confused as to why it stopped working when I used the controlrepo template
j
Thanks all for your confirmation on this, very helpful! Our currently plan is only raise the "undefined variable" exception when 
Puppet[:strict]
is enabled (the default in puppet8 and the variable lookup occurs during a catalog compilation.
👍🏻 1
t
FWIW, you can also [add various facts into the certificates](https://www.puppet.com/docs/puppet/7/ssl_attributes_extensions.html) and then automatically get them in 
$trusted[extensions]
2 Views
Open in Slack
PreviousNext
Powered by