On Thu, Mar 07, 2013 at 12:11:09PM -0800, James Ralston wrote:
> 
> At this point, all of the modules we have written use parameterized 
> classes. That way, when we call the module from the host's node.pp file, we 
> can override defaults (if necessary).
> 

I lump all nodes into the node default and send all hosts thru one
manifest.  It processes thru a hash of hashes derived from one yaml
file with lookups based on ${hostname} only.  There is no parameterized
classes in use.  $hostname is the only fact in use; we don't trust
the nodes facts.

node default {
    include processhosts
}

> 
> The main thing we're trying to understand is how each host manifest can 
> declare its own hiera hierarchy for data lookup. We can't do this with the 
> yaml backend, because the yaml backend will apply the same hierarchy to 
> EVERY client, because all Puppet clients use the /etc/puppet/hiera.yaml 
> file on the puppetmaster. Granted, we can customize the hierarchy on the 
> puppetmaster with facter facts, but that doesn't give us enough control.
> 

You can use one yaml file for all hosts to accomplish the above.  

$ more hiera.yaml
---
:backends:
     - yaml
:hierarchy:
     - %{hostname}
     - common

I could overlay individual hostname.yaml files but I just keep the
hash of hashes in one yaml file, common.yaml.

$ more hieradata/common.yaml
servers         :
  node-a :
                        sshd_auth: local
                        ClientAliveInterval: nil
                        ClientAliveCountMax: nil
                        server_role: site-server
                        location: []
                        smtp-server: nil
  node-b :
                        sshd_auth: local
                        ClientAliveInterval: nil
                        ClientAliveCountMax: nil
                        server_role: site-server
                        location: []
                        smtp-server: nil
  node-c :
                        sshd_auth: ldap
                        ClientAliveInterval: nil
                        ClientAliveCountMax: nil
                        server_role: linux-site-server
                        location: []
                        smtp-server: postfix


$ more modules/processhosts/manifests/init.pp

     class processhosts {

        $all_data = hiera_hash('servers')
        $node_data = $all_data[$hostname]

        $sshd_type = $node_data['sshd_auth']
        $server_role = $node_data['server_role']
        $ClientAliveInterval = $node_data['ClientAliveInterval']
        $ClientAliveCountMax = $node_data['ClientAliveCountMax']
        $location = $node_data['location']
        $smtp = $node_data['smtp-server']

            notice "my name is $hostname and I am using hiera from YAML"
            notice ( "setting sshd_type:  $sshd_type" )

            case $server_role {
                site-server: {
                    notice "${hostname} is a site-server"
                }
                linux-site-server: {
                    notice "${hostname} is a linux-site-server"
                }
                linux-site-vm: {
                    notice "${hostname} is a linux-site-vm"
                    include pkg::apt
                }
                general: {
                    notice "${hostname} is a general-server"
                }
                fbsdhost: {
                    notice "${hostname} is a fbsdhost"
                    include admin::snmpd
                }
                nil: {
                    notice "${hostname} is a server of undefined type"
                }
                default: {
                    notice "${hostname} is a server of undefined type and not 
nil"
                }
            }

            case $mysudo {
                '': {
                include admin::sudo
                }
            }

    }

The processhosts module imports other manifests based on the hostname
lookup of the 'servers' hash of hashes in common.yaml.  This has
proven to be sane and flexible.  If the node isn't defined in the
common.yaml, you get a catalog error "err: Could not retrieve
catalog from remote server:."  

Regards,
-dkw

-- 
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 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.


Reply via email to