I'm having a difficult understanding variable precedence and design intent when it comes to hiera. In the pupmod-simp-auditd module, the variable auditd::q_depth is defined in the init class and also in the hiera common.yaml file. If the client on which Puppet runs does not meet the criteria based on hiera.yaml of the module, wouldn't heira use the value in common.yaml instead of the init.pp file? If so, what is the purpose of having the q_depth variable set to a value in init.pp? Is this just an oversight?

It's an oversight (i.e., redundant)

It's an oversight (i.e., redundant)

However, it's not technically redundant because the values differ. The same can be said for $priority_boost and other variables, too. Which value takes precedence?

Precedence is Hiera > Code default value: https://www.puppet.com/docs/puppet/6/hiera_automatic.html#class_parameters

Thanks for noting the discrepancy, will enter a ticket for it

In my testing, the value for priority_boost came from common.yaml.

So the next question is, "If the variable is 'defined' in common.yaml, is it prudent to remove the value of that variable from init.pp?"

That follows the documented precedence

Yes, especially if it doesn't match

(but in the case of conflicts like this, we'd first confirm which value is preferred)

(but in the case of conflicts like this, we'd first confirm which value is preferred)

I'll keep an eye on the auditd project for the change.

Is it causing an operational issue for you in some way?

If so, a quick workaround is to provide a value that you want in hiera or through resource-style class declaration.

If so, a quick workaround is to provide a value that you want in highra or through resource-style class declaration.

If so, a quick workaround is to provide a value that you want in hiera or through resource-style class declaration.

Not an operational issue. I'm having a hard time determining where I should put the default values for variables in my init.pp. Should the variables' default values be defined in init.pp or common.yaml?

I've reached the limit of my coding skills and am trying to improve some modules I've written and I'm having a hard time determining where to assign the default values.

Putting the default values in common.yaml seems to obfuscate things.

I understand the other hierarchies but why things are in common.yaml confuses me. Is that to support a lookup query?

I’d recommend editorconfig plugin as well to use .editorconfig settings (indent size, line endings, etc)

Unless you are forking auditd, You probably shouldn't change either. For simplicity's sake, we tend to prefer simple defaults (ones that don't benefit from an actual hierarchy in hiera) to be declared in the parameter code.

Generally you'll put things in common.yaml to provide defaults for parameters that are overwritten elsewhere in other hierarchy tiers.

No, I'm not changing auditd. I'm using auditd as a template for best practices for my modules.

If you put things in common.yaml, then why are all the variables in init.pp initialized with default values?

I’d recommend voxpupuli’s puppet-chrony as a reference

See the

puppet-chrony

module at https://forge.puppet.com/puppet/chrony?src=slack&channel=puppet

@Brian Schonecker without checking the git history, my best guess is that the module started with all defaults and some weren't removed when added to Hiera.

The best practice is usually to only set your values using hiera, especially in a component module. Hiera is, as @op-ct mentioned earlier, always consulted first. The way I always described hiera to my students when teaching classes is that you create class parameters so something can populate those values. Hiera is the something that is intended to do that. Technically, that's not what it was originally designed for, but once automatic parameter lookup became a thing, it has become it's primary use ever since.