Puppet Community

So, yeah.  The version parameter to the puppet-r10k module.

See the `puppet-r10k` module at <https://forge.puppet.com/puppet/r10k?src=slack&amp;channel=puppet>

I have this for awhile
```  class { 'r10k':
    version  =&gt; '&gt;= 3.2.0',```

last time I really needed to upgrade :slightly_smiling_face:

<https://github.com/puppetlabs/r10k/blob/main/lib/r10k/version.rb>

r10k is still owned by Puppet/Perforce. puppet-r10k, the module for r10k, was never owned by Puppet/Perforce and is maintained by Vox Pupuli

that’s why I pointed to the Puppet version rather than Vox

Finch wrote the original `r10k` tool itself (along with some other Puppet PSE’s at the time).
Zack wrote the Puppet module to install r10k, <https://forge.puppet.com/modules/zack/r10k>

The tool it still owned by Puppet, but the module has been moved to VoxPupuli.

I had used zack-r10k for like EVER and then suddenly I had to go hunting for what had happened one day

See the `zack-r10k` module at <https://forge.puppet.com/zack/r10k?src=slack&amp;channel=puppet>

I guess I never needed anything above 3.2 :slightly_smiling_face:

wait what… it can skip the spec/ directory?

<https://github.com/puppetlabs/r10k/blob/main/doc/dynamic-environments/configuration.mkd#exclude_spec>

Does that also apply to modules in the control-repo itself? e.g. `site-modules/`

Does that also apply to modules in the control-repo itself? e.g. `site-modules/`?

so... it seems that you can't set class param with a name of tag via hiera automatic binding...

Indeed, I did something dumb and used a metaparameter for a class name... I know better... What is annoying is that rspec-puppet tests ran fine in the module.  It didn't blow up until puppet `&lt;class&gt;::tag: &lt;foo&gt;` into hiera in my control repo.

the catalog compile should fail if metaparams are declared as regular class parameters....

I believe there should be puppet-lint plugin for this :)

Agree with <@U1QVBAUS2> the compiler should check reserved names.

<@U111Z4JR1> Do you know if there is an existing jira issue that covers this?

or is it just a command we could run when we want?

yes, it would be a command line report, with human readable tabular and json output options

a consideration would be, for example, the stdlib module. Most people don’t declare the `stdlib` class, so it would likely be marked unused. If you had 25 different environments, that could be 25 lines in the report if we broke it out :face_with_raised_eyebrow:

I may have just talked myself into it. I’m thinking that infrastructures with environments that are nearly duplicates of one another won’t have a large number of environments — and infras with large numbers of environments will usually be totally unrelated and so they will want the per env reporting.

For my use cases, only production make sense, all the rest are feature branches that might be a few commits more or lagging behind for too long

That's how I typically think about puppet infras too

I would also say development because we operate with gitflow practices

Hmm. Maybe I'll go with non correlated for now, since I've already completed that. And then see how many bug reports I get :grin: 

Can do an overall report with a way to expand the line and see where exactly the module is.. unused :)

But anyway.. as long as it's json one can leverage jq to filter out what is needed/unneeded

<@U11HA7VJ7> <https://github.com/voxpupuli/puppet-ghostbuster> might be useful as well

So, make sure you take base module path into account for this bit (maybe an option to enable/disable.)  At least here, we only put modules into the environment that are specific to the env, anything that's shared more then a couple times goes into a set shared r10k puppetfiles for the infra/app enablement/database teams to manage

<@U1PC2RAH0> I’m also going to reference that in the tutorial I’m writing

<@U020LK7D0JU> basically, I’m just querying the puppetserver for the modules and classes it knows about. Not looking at the filesystem itself.

<@U1PC2RAH0> (also, ghostbuster existing is part of the reason I don’t want to get too granular here)

Reminds me of what ghostbuster was made for. The option sounds very helpful. Especially in environments which are long living and very different to each other. 

there’s room for both. This is for a higher level reporting tool that ships with puppetserver and ghostbuster is a dev tool that uses puppet-lint and ties into your dev/ci workflow.

next week I’ll have a tutorial up on how to use it, and the week following will have another about ghostbuster

question for y’all. If you had a list of unused modules and/or classes — installed but not actively used — would it be useful to list them per environment, or would that just be information overload?

hmmm
The answer may be that it was an unnecessarily complicated module that can be replace with a couple of package installs