Hi,
Looking at how our hiera levels are already exploding due to some
preferences, I'm wondering how others describe use hiera.
We have a preference to group related data within separate files, however
some colleague concerns about using '%{module_name}' and '%{calling_class}'
means that for each separate application related class within our main
module we end up with a dedicated level in hiera.
While our existing hierarchy doesn't quite look like the following, once
we've migrated to using a eyaml backend (in addition to the current yaml
backend) instead of a separate restricted access git repo I expect to see
it look like the following:
:hierarchy:
- "node/%{::domain}/%{::hostname}"
- "gerrit"
- "database"
- "jenkins"
- "server"
- "web"
- "%{calling_class}"
- "%{module_name}"
- defaults
Tbh, I'd favour simply doing something like the following:
:hierarchy:
- "node/%{::domain}/%{::hostname}"
- "%{calling_class}"
- "%{module_name}"
- defaults
And have anything in 'gerrit', 'database', 'jenkins', 'server' & 'web' that
needs to be accessible by other classes placed in 'defaults' and for
anything specific to that class simply put in a name that is picked up by
'%{calling_class}'.
However there are concerns that it's difficult to remember that data is
only visible to the associated class/module when made accessible under
'%{calling_class}' and '%{module_name}', and I think '%{module_name}' goes
away in hiera 5 or at least it's deprecated and support for it will be
removed in hiera 6.
What concerns me however is whether there is a performance impact of
creating lots of levels to keep data nicely separately on a
service/application basis in the name of keeping it easy to understand.
Do others simply use a single file? Or do you favour use of
'%{module_name}', '%{calling_class}', and/or '%{calling_class_path}'? If so
what are your plans around hiera's future behaviour?
Any clues on assessing the performance impact of either approach? I doubt
it currently makes much difference, but I'm sure as we add more and more
puppet code to manage additional services/applications and consequently
many more levels this will have to start impacting at some point.
Perhaps it makes more sense to have these in separate files and then a
additional step to the deployment that combines the application specific
files into a single yaml entry to be used by hiera. Giving us separation at
the source/review level and simple single file at the point of usage to
ensure good performance.
It also seems to more in line with hiera as these application specific
files are not really separate levels of hierarchy, they are just separated
for human reading convenience.
Anyone care to provide some insight:
Have you encountered this?
Do you just stick everything for different services/applications in the
same file?
Does that isolate which puppet modules/classes where that data is
accessible from?
Do you prefer explicit isolation though using the special variables? and
just trust that people remember these are not visible everywhere?
--
Darragh
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/8d142857-c985-4902-9346-aaeb577dc2e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
