I have tried restarting puppet master [root@puppetmaster ~]# service puppetmaster restart
Also, I have stopped the puppetmaster daemon and run it from the command line: [root@puppetmaster ~]# /usr/bin/puppet master -d --no-daemonize .... Debug: hiera(): Hiera YAML backend starting Debug: hiera(): Looking up apache_vhosts in YAML backend Debug: hiera(): Looking for data source node1 Debug: hiera(): Looking for data source RedHat Debug: hiera(): Looking for data source common .... On Wednesday, June 5, 2013 10:32:07 AM UTC-6, Keith Burdis wrote: > > You need to restart the Puppet Master process if you change hiera.yaml. > > - Keith > On 5 Jun 2013 17:09, <[email protected] <javascript:>> wrote: > >> Yes and it seems to work >> >> [root@puppetmaster ~]# hiera classes -c >> /etc/puppet/environments/testing/hiera.yaml environment=testing >> role=webserver fqdn=node1 --debug -a >> DEBUG: Wed Jun 05 10:02:23 -0600 2013: Hiera YAML backend starting >> DEBUG: Wed Jun 05 10:02:23 -0600 2013: Looking up classes in YAML backend >> DEBUG: Wed Jun 05 10:02:23 -0600 2013: Looking for data source node1 >> DEBUG: Wed Jun 05 10:02:23 -0600 2013: Found classes in node1 >> DEBUG: Wed Jun 05 10:02:23 -0600 2013: Looking for data source webserver >> DEBUG: Wed Jun 05 10:02:23 -0600 2013: Found classes in webserver >> DEBUG: Wed Jun 05 10:02:23 -0600 2013: Looking for data source common >> DEBUG: Wed Jun 05 10:02:23 -0600 2013: Data retrieved from >> /etc/puppet/environments/testing/hieradata/common.yaml is not a Hash, >> setting defaults >> ["keepalived", "apache"] >> >> >> On Wednesday, June 5, 2013 9:53:25 AM UTC-6, Ygor wrote: >>> >>> have you tried running hiera on the command line with debug ? >>> >>> “Sometimes I think the surest sign that intelligent life exists >>> elsewhere in the universe is that none of it has tried to contact us.” >>> Bill Waterson (Calvin & Hobbes) >>> >>> ------------------------------ >>> *From: *[email protected] >>> *To: *[email protected] >>> *Sent: *Wednesday, June 5, 2013 11:43:24 AM >>> *Subject: *Re: [Puppet Users] Share Hiera configuration between 2 nodes? >>> >>> Ok maybe I spoke too soon... >>> >>> It looks like the hiera hierarchy is not seeing the custom fact and as a >>> result is not applying the corresponding .yaml file. I expected it to load >>> the hieradata\webserver.yaml file. However as the puppetmasterd debug log >>> shows that it skips over this and loads the osfamily .yaml file. >>> >>> *hiera.yaml * >>> --- >>> :backends: >>> - yaml >>> :yaml: >>> :datadir: /etc/puppet/environments/%{**environment}/hieradata >>> :hierarchy: >>> - %{fqdn} >>> - %{role} >>> - %{osfamily} >>> - common >>> >>> *Puppetmasterd debug messages* >>> *...* >>> Info: Caching node for node1 >>> DEBUG: Wed Jun 05 09:11:50 -0600 2013: Looking up apache_vhosts in YAML >>> backend >>> DEBUG: Wed Jun 05 09:11:50 -0600 2013: Looking for data source node1 >>> DEBUG: Wed Jun 05 09:11:50 -0600 2013: Looking for data source RedHat >>> DEBUG: Wed Jun 05 09:11:50 -0600 2013: Looking for data source common >>> Notice: Compiled catalog for node1 in environment testing in 0.04 seconds >>> *...* >>> >>> >>> *Contents of hieradata folder:* >>> [root@puppetmaster~]# ls /etc/puppet/environments/**testing/hieradata/ >>> common.yaml webserver.yaml node1.yaml node2.yaml RedHat.yaml >>> >>> >>> *Contents of /etc/facter/facts.d/role.yaml* >>> --- >>> role: webserver >>> >>> *node1* >>> >>> [root@node1 /]# puppet agent -t --environment=testing >>> Info: Retrieving plugin >>> Info: Loading facts in /var/lib/puppet/lib/facter/** >>> iptables_persistent_version.rb >>> Info: Loading facts in /var/lib/puppet/lib/facter/**facter_dot_d.rb >>> Info: Loading facts in /var/lib/puppet/lib/facter/**root_home.rb >>> Info: Loading facts in /var/lib/puppet/lib/facter/**puppet_vardir.rb >>> Info: Loading facts in /var/lib/puppet/lib/facter/**iptables_version.rb >>> Info: Loading facts in /var/lib/puppet/lib/facter/pe_**version.rb >>> Info: Loading facts in /var/lib/puppet/lib/facter/**concat_basedir.rb >>> Info: Loading facts in /var/lib/puppet/lib/facter/**ip6tables_version.rb >>> Info: Caching catalog for node1 >>> Info: Applying configuration version '1370444163' >>> Notice: The value is: webserver >>> Notice: /Stage[main]//Node[node1]/**Notify[The value is: >>> webserver]/message: defined 'message' as 'The value is: webserver' >>> Notice: Finished catalog run in 0.31 seconds >>> >>> *Facter test* >>> [root@node1 /]# facter -p role >>> webserver >>> >>> *Puppet Versions* >>> [root@node1 /]# facter --version >>> 1.7.1 >>> [root@node1 /]# puppet --version >>> 3.2.1 >>> [root@puppetmaster ~]# facter --version >>> 1.7.1 >>> [root@puppetmaster ~]# puppet --version >>> 3.2.1 >>> >>> Thanks for the help! >>> >>> On Tuesday, June 4, 2013 2:09:48 PM UTC-6, Keith Burdis wrote: >>>> >>>> You could set a custom "role" fact on node1 and node2 with the value >>>> "webserver" and then use the "role" fact in your Hiera hierarchy. >>>> >>>> For example using facter.d on on node1 and node2: >>>> >>>> # cd /etc/facter/facts.d >>>> # echo 'role: webserver' >> custom_facts.yaml >>>> # facter -p role >>>> role => webserver >>>> >>>> and on the master: >>>> >>>> # cat /etc/hiera.yaml >>>> ... >>>> :hierarchy: >>>> - %{role} >>>> ... >>>> >>>> with the common configuration in webserver.yaml under your Hiera >>>> datadir. >>>> >>>> - Keith >>>> >>>> >>>> >>>> On 4 June 2013 20:41, <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> I am trying to use Hiera in puppet 3 and I have two nodes that both >>>>> need the same configuration. In this case they are two web servers which >>>>> have the same apache configuration. >>>>> >>>>> Rather than creating two seperate hiera files for node1.yaml and >>>>> node2.yaml is there a way to group these by role (e.g. webserver.yaml)? I >>>>> want to avoid duplicating the configuration if possible and keep the data >>>>> in hiera. >>>>> >>>>> Thanks! >>>>> Joe >>>>> >>>>> -- >>>>> 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...@googlegroups.**com. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at http://groups.google.com/** >>>>> group/puppet-users?hl=en<http://groups.google.com/group/puppet-users?hl=en> >>>>> . >>>>> For more options, visit >>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>>> . >>>>> >>>>> >>>>> >>>> >>>> -- >>> 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...@**googlegroups.com. >>> To post to this group, send email to [email protected]. >>> Visit this group at >>> http://groups.google.com/**group/puppet-users?hl=en<http://groups.google.com/group/puppet-users?hl=en> >>> . >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>> . >>> >>> >>> >> -- >> 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] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> Visit this group at http://groups.google.com/group/puppet-users?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
