Many thanks for your reply Gavin. I have basically gone down this route in my thinking too, except rather than use a fact, I will set up our ENC (a custom ENC we've written) to set a global variable 'role' which can then be used to drive the hiera hierarchy.
A fact would mean we would have to set the role on the client, or worse, set it via Puppet and then read it on a second run or via puppet stages. That sounds...horrible. It is a real shame that the ENC functionality in Puppet and Hiera are so disconnected, it would be fantastic if you could set Hiera variables through the ENC. Oh well. Cheers, David On Sunday, 17 July 2016 17:03:33 UTC+1, Gavin Williams wrote: > > David > > If you can expose the role as a top-level fact, then you can use that to > drive the hiera hierarchy. You can then override the required class params > in a role specific yaml file. > > HTH > Gav > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/6086ab0a-812f-478e-b48f-ef4605040b0b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
