hiera hierarchy by network

104 views
Skip to first unread message

Peter K

unread,
Apr 13, 2017, 12:21:02 PM4/13/17
to Puppet Users
This network lookup is simple and works well...but only on some clients because they have more than one network interface:
hiera.yaml:
---
:hierarchy:
 
- "%{::trusted.certname}"
 
- "%{::network}"
 
- common

It fails on some machines because they have docker virtual interfaces and instead return a network name like 172.0.0.0 instead of the one I want: 10.1.1.0.
It seems the lookup just picks the first interface listed in the ::networking array.
Are there any other methods to do lookups based on the network? I want to match the same network that puppet is working on.

My experience is I can't easily parse the hiera lookup for ::networking (asked here) but maybe I can with hiera5 with globs.
Thx,
-peter

Rob Nelson

unread,
Apr 13, 2017, 6:30:22 PM4/13/17
to puppet...@googlegroups.com
Try the structured facts. $facts['networking']['network'] is probably somewhat indeterministic, but if your interface names are predictable, then $facts['networking']['interfaces']['ens192']['network'] (or 'eth0' or whatever) could conceivably be the value you need.

Having tried to fight with this before, however, I went with an external fact. I don't need the network so much as I need the datacenter and I just create the file `/etc/facter/facts.d/datacenter` in my templates or during provisioning, so I never need to deal with some wacky new network that isn't correlated to a datacenter until I touch some code again. Something like that might be helpful even if you can get the structured fact right, as the provisioning process is often a better spot to insert such values.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0593fc69-c51e-4176-a4c8-c28840ac59a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Peter K

unread,
Apr 14, 2017, 3:23:49 PM4/14/17
to Puppet Users
Thank you Rob. I've been close to experimenting with custom facts but haven't tried yet. I think I can stick with what I have for now and just watch out of breakage...at which point I'll create a custom fact.
-peter

Nick Fagerlund

unread,
Apr 28, 2017, 7:28:53 PM4/28/17
to Puppet Users

I THINK the new mapped_paths feature in Puppet 4.10 can do this, when combined with the networking fact. Um, I think it'd look something like this:

hierarchy:
  - name: "Network interface (tries all interfaces)"
    mapped_paths: [facts.networking.interfaces, interface, "networks/%{interface.1.network}.yaml"]

Since facts.networking.interfaces is a hash, the local value of "interface" is an array with one key/val par, so something like ["en0", { hash of stuff, where we want the key 'network' }], hence interface.1.network.

Nick Fagerlund

unread,
Apr 28, 2017, 7:29:20 PM4/28/17
to Puppet Users
Reply all
Reply to author
Forward
0 new messages