Hiera driving me round the bend

[David Murphy]

Hi Guys, 

You have to forgive this but it’s driving me nuts. 

I thought I understood the way that Hiera worked and trying to get it to work in the way I expect has had me seriously doubting myself. 

My hiera.yaml looks like this 

---

# Hiera 5 Global configuration file

  version: 5

  defaults:

    datadir: /etc/puppetlabs/code/environments/production/hieradata

    data_hash: yaml_data

  hierarchy:

    - name: "Host Specifics"

      path: "hosts/%{facts.hostname}.yaml"

    - name: "Attribute Specifics"

      mapped_paths: [ attributes, att, "attributes/%{att}.yaml" ]

    - name: "Application List Specifics"

      mapped_paths: [ applicationlist, app, "application/%{app}.yaml" ]

    - name: "Business Owner Specifics"

      path: "businessowner/%{facts.businessowner}.yaml"

    - name: "Environment Specifics"

      path: "environment/%{facts.role}.yaml"

    - name: "OS Specific"

      path: "os/%{facts.os.family}%{facts.os.release.major}.yaml"

    - name: "Kernel Specific"

      path: "kernel/%{facts.kernel}.yaml"

    - name: "Hardware Specific"

      path: "hardware/%{facts.productname}.yaml"

    - name: "Site Specific"

      path: "site/%{facts.deriversite}.yaml"

    - name: "Common Data"

      path: “common.yaml"

On the agent I’m setting up some local facts that I need to control what comes back in the catalog.

---

  derivedsite: 'cp1'

  hostdb:

    role: 'development'

    businessowner: ‘Infrastructure'

  attributes:

    - 'DNS-Slave'

    - 'Oracle'

  applicationlist:

    - ‘test'

The way I’m trying to debug this is via a parameter called sourcefact that is in all off the Hiera yaml files and is merged to show me which files are being used.

Local facts look like this 

---

# Yaml file for Hiera - Common

  lookup_options:

    sourcefact:

      merge: unique

    profile::packages::os:

      merge: unique

    "^profile::(.*)$":

      merge: deep 

  sourcefact: ‘Common'

When I run the puppet agent -t one of the lines looks like 

Notice: Let's see what the Source variable says [DNS Slave, test, Linux, Common]

Trouble is I can’t seem to get it to be consistent. The only facts I can seem to get the master to see are the attributes and applicationlist ones and they are both arrays end even then it only picks up the first element.

For this agent I would expect to see 

Notice: Let's see what the Source variable says [Oracle ,DNS Slave, test, Linux, cp1, Common]

I’m assuming I am doing something fundamentally wrong here - HELP!!!! 

[Martin Alfke]

Hi David,

You seem to mix up hiera and facts.

Your node has facts:

---
  derivedsite: 'cp1'
  hostdb:
    role: 'development'
    businessowner: ‘Infrastructure'
  attributes:
    - 'DNS-Slave'
    - 'Oracle'
  applicationlist:
    - ‘test'

Now hiera jumps in (hiera.yaml file) and uses the facts to identify which hierarchies to use, when receiving queries for hiera keys.

Within hiera you can specify the way how hiera should look for keys (lookup_options).

These have nothing to do with facts!

Lets assume you hiera.yaml file and the following hiera content:

# common.yaml

---

lookup_options:

  ‘profile::attributes::name’:

    merge: unique

# attributes/DNS-Slave.yaml

---

profile::attributes::name: ‘DNS-Slave’

# attributes/Oracle.yaml

---

profile::attributes::name: ‘Oracle'

Within your Puppet code:

class profile::attributes (

  $name,

){

  notify { ‘attrlist’:

    message => $name,

  }

}

This will return all of the existing profile::attributes::name Hier keys available for a node in all hierarchies.

Using the above mentioned code and data this will return:

[‘DNS-Slave’, ‘Oracle’]

Hth,

Martin

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/3b96dd74-90c3-4cc4-8dff-55245deea3d3n%40googlegroups.com.

[David Murphy]

OK - I think my naming is a little confusing but I don't think that I am confusing the two - although I totally could be, 

The problem for me seems to be that the facts that the client should be passing through to the server don't seem to be handled properly. The way I'm trying to determine this - as I haven't got puppetDB setup is to have a key in each of the yaml files in the hierarchy and by merging that key it will show me all of the yaml files making up the data being provided to the agent.

The things that I don't understand are these

• The docs say that if you want to use a fact in your hiera.yaml to specify a path you should do it like this 
  

            path: "site/%{facts.derivedsite}.yaml"

            but even though I can see that fact using facter -p on the agent it doesn't pick it up on the master.

• How does the mapped_paths work? 

            mapped_paths: [ attributes, att, "attributes/%{att}.yaml" ]

            This works even though the attributes array is specified as a fact on the agent server. But it doesn't work if I use facts.attributes instead which If the docs are to be believed you should do. Also, although the mapped_paths is supposedly allowing me to have files for all of the array elements it doesn't pick up both.