Hi Rob,
Thanks for some of the suggestions, I suspect part of our problem is that
we have multiple applications/services deployed per node using docker
containers.
We probably can't easily map a single role per machine because we want to
be able to move the application/services between machines relatively
easily. This kind of suggests this should all be in a single layer such as
the datacenter one suggested. Although our usage of the '%{calling_class}'
is analogous to your '%{puppet_role}' above, see comment below.
On Monday, March 20, 2017 at 3:30:12 PM UTC, Rob Nelson wrote:
>
> If you're looking up hiera data based on the calling class, I'd question
> whether that's useful to split out to hiera at all - every instance of the
> class would get the same values, right? And would you really want ALL nodes
> that `include jenkins` to get the same jenkins server? Even if they're in
> DCs on opposite sides of the world supporting different groups?
>
Have a tendancy to use a specific class for a specific instance that can
then 'include jenkins'. To properly make use of calling_class across the
board to collapse our levels, would need to rename the yaml files so
jenkins -> local_module_name::my_jenkins, gerrit ->
local_module_name::my_gerrit, etc.
This meant that the information would only be available when configuring
that specific service and if we needed two of them, we would end up
creating two separate classes wrapping the same specific base class in
order to pull in the desired info.
Seems to follow the idea of similarly the information for specific roles is
only available to those systems with the given roles.
> It's more likely that you want to use some facts about the nodes -
> datacenter, network, owning organization, etc. - to provide that data. Your
> hierarchy should be modeled after that. Mine is:
>
> :hierarchy:
> - "clientcert/%{clientcert}"
> - "puppet_role/%{puppet_role}"
> - "osfamily-release/%{osfamily}-%{operatingsystemmajrelease}"
> - "datacenter/%{datacenter}"
> - global
>
> Clientcert lets individual nodes override settings groups normally
> inherit; puppet_role is a custom fact reflecting a service like AppX, AppY,
> DHCP, DNS, etc; the next tier is OS since we run a few versions that often
> require different values; next is the datacenter, where routes and DNS and
> such might differ; and finally global is things standardized across the
> board (called 'common' in default installations). IMO, the only tier that
> should reference a single filename would be global/common, anything else
> doing so is really just replicating that tier higher up the stack and
> adding complexity. I'm sure there's some valid use case for it, though.
>
This is closer to a layout I had expected to be used, and it was the
desired to split up some of the information into management chunks that
drove the separate files.
> There's some perf impact when you have more tiers, but hiera lookups don't
> have a high enough cost for us to worry about it. There is a cost to
> architecting and maintaining additional tiers and that's my main concern.
> You can only keep so much in your head, so it's easy to lose track of where
> things are configured and where they should be configured, and of course it
> affects troubleshooting times as well.
>
> I believe that answers some of your questions and obviates the need for
> answers to others.
>
Thanks, I've a feeling we'll have to think about the hiera layers some more
and how data is organized in order to get a better handle on it.
> Rob Nelson
> rnel...@gmail.com <javascript:>
>
>
--
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/e157dac1-a87d-473c-9915-5306d3214866%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
