using multiple facter values with hiera

[Paul Archer]

I've got a custom fact that spits out a list of server types (web, app, db, etc). I'd like to do classification on this fact, but when I try using one of the server types in my hiera config, it doesn't work. 

For simplicity, I've tested with another fact (filesystems) that also returns multiple values.

# this is a typical facter output for filesystems

root@puppetmaster:/etc/puppet/hieradata# facter filesystems

ext4,iso9660

# my hiera.yaml, to show the first entry in my hierarchy is for the filesystems fact

root@puppetmaster:/etc/puppet/hieradata# cat /etc/hiera.yaml

---

:backends:

  - yaml

:hierarchy:

    - "%{filesystems}"

    - global

    - "nodes/%{clientcert}"

    - "groups/%{server_groups}"

    - "environment_%{environment}"

    - "os/%{osfamily}"

    - "os/%{osfamily}/%{operatingsystemmajrelease}"

    - "virtual_%{::virtual}"

    - defaults

    - credentials

:yaml:

  :datadir: /etc/puppet/hieradata

# my yaml file has a an entry for motd::banner (my 'play with' data)

root@puppetmaster:/etc/puppet/hieradata# cat /etc/puppet/hieradata/ext4.yaml 

---

motd::banner: this is for the ext4 filesystem

# without any facts, I get the default

root@puppetmaster:/etc/puppet/hieradata# hiera motd::banner

Hi there! This system is managed by puppet. (defaults.yaml)

# with the filesystem fact set to ext4, I get the right value

root@puppetmaster:/etc/puppet/hieradata# hiera motd::banner filesystems=ext4

this is for the ext4 filesystem

# with the filesystem fact set to exactly what I get from facter, I'm back to the default

root@puppetmaster:/etc/puppet/hieradata# hiera motd::banner filesystems=ext4,iso9660

Hi there! This system is managed by puppet. (defaults.yaml)

Is it possible to use a fact that contains multiple values within hiera? If so, what am I missing? If not, what's the point of having facts with multiple values in the first place?

Paul

[William Leese]

Facter was designed before hiera. It serves a larger purpose than just usage as hiera hierarchy conditionals.

Do I understand correctly that your custom fact which "spits out a list of server types" returns more than 1 item in a comma separated list like the filesystems example you provided?

Looking at the nature of this custom fact would it not be better if it provided a single 'server type'? If this is impossible, you could split the fact into X facts and (servertype1,servertype2 and servertype3) which could then be used nicely in hiera.

If your custom fact is outputting a highly variable string (that looks like multiple values due to a comma), then it's not really suitable to use in hiera.yaml I believe.

[Paul Archer]

On Wednesday, December 11, 2013 11:03:33 PM UTC-6, William Leese wrote:

Facter was designed before hiera. It serves a larger purpose than just usage as hiera hierarchy conditionals.

I get that. 

 

Do I understand correctly that your custom fact which "spits out a list of server types" returns more than 1 item in a comma separated list like the filesystems example you provided?

Exactly. I used the filesystems example for simplicity (you can try it without setting up a custom fact), and because it has exactly the same behavior as my target fact.

 

Looking at the nature of this custom fact would it not be better if it provided a single 'server type'? If this is impossible, you could split the fact into X facts and (servertype1,servertype2 and servertype3) which could then be used nicely in hiera.

To make this work in hiera I'd need a hierarchy like:

  - "groups/%{servertype1}" 

  - "groups/%{servertype2}" 

  - "groups/%{servertype3}" 

It's clunky, but the more I think about it, the more I think that's the only way to do this. I just realized that hiera doesn't have any way to iterate over the list handed to it from facter. So if my servertype fact is equal to git,ntp,ldap (for example), then I can't expect hiera to do a lookup with the fact servertype set to git, then another lookup with the fact servertype set to ntp, etc. I think it's reasonable to *want* this behavior, but it's not what it does (for now, at least).