That is a best practice, not the best practice.

puppet-chrony defines defaults in init.pp and doesn't have a common.yaml file. So now I'm even more confused.

See the

puppet-chrony

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

That's fair enough. I have found that it's helpful to set default values AND hiera, just to avoid having to go back and forth when trying to figure out what default values are supposed to be.

If the variable is set to a default in init.pp AND is defined in common.yaml, then what I'm seeing is that the value comes from common.yaml.

But that can also be confusing and lead to this particular conversation lol

Indeed.

This message was deleted.

Perhaps this is an example of "Doctor it hurts when I put values in init.pp and common.yaml."

It makes a lot more sense to me for the default values to be in init.pp as I don't have to go hunting for them.

However, it also makes sense to me to put lengthy hashes in common.yaml to reduce the clutter in init.pp.

As someone who works with the simp modules regularly, yes. Assume all of them have a good amount of technical debt. They're very well written and maintained modules, but they were written at a diferent time in puppet's development. The OnyxPoint team has done a remarkable job of modernizing them over time, but SIMP is big, and it takes time to move things forward.

This message was deleted.

+1 about tech debt and big :P

@wil.rodriguez For simple default values that don't change under conditions, it is we've found it often more practical to keep parameter defaults along with the code definition. Puppet Strings will include the default, and the code is easier to to reason about and review (most code reviewers do not configure/execute

puppet lookup

locally)

I've got a custom module I'm writing and it needs four filesystems mounted which requires a dirtree, directory, LVM, etc. That would quickly overwhelm the init.pp file but it's easier to read in common.yaml.

@wil.rodriguez For simple default values that don't change under conditions, it is we've found it often more practical to keep parameter defaults along with the code definition. Puppet Strings will include the default, and the code is easier to to reason about and review (most code reviewers do not configure/execute

puppet lookup

locally)

Then that's the right answer

Yeah, I'm gonna have to do a balancing act and not double-define variable defaults in init.pp and common.yaml. Thanks everyone for helping out this old dog.

I agree, and in my previous role as the primary guiding puppet SME at USAA, I advised this as well. Default values that live inside of the puppet code are far easier to find than hunting through any number of different layers of hiera for a value. This is extra true when you're working in profiles rather than component modules. That said, puppet isn't exactly known for its top tier performance. It's a DSL of an interpreted language. So, it is definitely often preferable to short circuit the lookup for default values and put as much in hiera as possible so it can be caught by the blazing fast C++ based hiera libraries rather than being punted back over to ruby. Granted, it's only a single layer of separation in many cases, but that can add up in large environments.

I wouldn't expect a performance hit in the case of parameter defaults―if APL is looking up a parameter, the Puppet code for that class has already been interpreted, including its parameters' default values. 🤔

@Brian Schonecker Vox Pupuli best practice is to add data directly to the class and use hiera in modules when the defaults are OS specific. puppet-strings will pick up the data from the classes/defined resources and render them into the REFERENCE.md. puppet-strings doesnt read hiera

@bastelfreak thank you for the information. Now I have to learn puppet-strings as I've not heard of that before.

ah 😄

that's the inline annotations we do

I have much more to learn before I can even think about contributing to Vox Pupuli.

https://github.com/voxpupuli/puppet-dbbackup/blob/master/manifests/init.pp#L1-L18 as an example

https://github.com/voxpupuli/puppet-dbbackup/blob/master/manifests/init.pp#L1-L18 as an example

naaa

I don't think so