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.
On Thursday, October 14, 2021 at 1:48:18 PM UTC+1 Martin Alfke wrote:
> 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
>
>
> On 10. Oct 2021, at 21:48, David Murphy <da...@weaverslodge.co.uk> wrote:
>
> 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!!!!
>
> --
> 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
>
> <https://groups.google.com/d/msgid/puppet-users/3b96dd74-90c3-4cc4-8dff-55245deea3d3n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
>
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/de7ceb68-54b9-4b29-9646-83181872865en%40googlegroups.com.
