On Thu, Jun 28, 2012 at 08:04:09PM +0100, R.I.Pienaar wrote:
> I would make facts on the nodes for these. Let say $role and $subrole
> and then just use those in your hierarchy with %{role} and %{subrole}
> thus allowing you to set variable for all those machines there.
Howdy:
I was wondering what is the best way to manage custom facts for a
disparate group of servers that need to report different fact values
for the same fact name? I am about to embark on hiera-based puppet
architecture and want to archetect it only once. I have some doubts
about the recommended ways of rolling out facter as it can get messy
burying facter server host configuration logic in disparate modules.
Let's say you want to create only one custom fact script to manage
all your facts based on data center location and functional server
host grouping. You decide you can manage all your custom facts
from one ruby/facter script if you create a ruby function using a
hash with your facter matching hostnames loaded in the hash as the
key and you can lookup location and function. Now you have to
choose which module to roll it from, but it's arbitrary.
Would one hash in a single custom facter script be enough configuration
for the all the hosts? I argue it would as you can add rows and
columns to the hash, so it should be able to support all your facter
needs. Either using custom facts or loading in all your hosts into
a hiera hash, you still have to know your hostnames.
However, why bury your custom facter script in a module with all
the configuration in there too? The current architecture and
directed use of facter alongside puppet/hiera seems to go against
the nature of moving your configuration out of manifests as the
direction of puppet/hiera is headed now.
I was thinking of creating a hiera hash or two (I am using YAML so
far. I could use as many hashes as required but one should be
enough probably, plus any arrays), including the information/configuration,
grouping servers by location and function, minimally. In my puppet
modules I can use hiera to call up my hash and create ruby/puppet
functions to do the server host location and functional logic based
on the default facter facts of hostname and operatingsystem reported
by the server host themselves. All the configuration remains in
hiera and the module manifests remain puppet business logic.
Comments?
Regards,
-dkw
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
