On Mon, Apr 8, 2013 at 2:28 PM, Tony C wrote:
After reading several posts, it looks like setting a key on every host,
and supplying a different value based on that host's function is not a
proper use of facts, but more for variables.
We are using hiera, and based on my hierarchy,
:hierarchy:
- common
- %{application}
:yaml:
:datadir: /etc/puppetlabs/hieradata/%{environment}
Without using an ENC, what's are some good ways to "tag" the server with a
value for %{application}.
After reading several posts, it looks like setting a key on every host,
and supplying a different value based on that host's function is not a
proper use of facts, but more for variables.
We are using hiera, and based on my hierarchy,
:hierarchy:
- common
- %{application}
:yaml:
:datadir: /etc/puppetlabs/hieradata/%{environment}
Without using an ENC, what's are some good ways to "tag" the server with a
value for %{application}.
using puppetlabs_stdlib module to provide simple custom facts from
/etc/facter/facts.d (after partitioning and installing a base OS) our
install process writes a custom text file to this directory defining facts
for "role", "group" and "cluster" which are all parts of our hiera
hierarchy and then calls puppet for the first time.
This may not be the best way in a more orderly environment but I work in an
academic research lab so have lots of messy edge cases that can't be
determined by name or IP and need to delegate these definitions to people
who are not admin enough to have access to our puppet repo but do have
local root on the systems they manage...
-Jon
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
