Puppet Community

<@UMYTA2U7N> thanks just spotted that, but it appears my lookup is failing from the cli, probably need to understand why that's failing before the problem with that specific lookup

The `--explain` output should help here. Maybe check for variables that aren’t expanding as expectecd.

`--explain` should show you where it looked. From there it's a matter of determining why an expected file was skipped.

because non-root looks in different place

Also note, you should be running that _on a puppetserver_, not from an agent.

the lookup is working, just need to fix the initial prometheus param lookup - which does look a legit problem with my definition

Hierarchy entry "Per-node data"
      Path "/etc/puppetlabs/code/environments/production/data/nodes/router.no-dns.co.uk.yaml"
        Original path: "nodes/%{trusted.certname}.yaml"
        No such key: "prometheus::bind_exporter::extra_options"

I'd done prometheus::bind_exporter: then extra_option: --stuff

needed to do prometheus::bind_exporter::extra_options: --stuff

Yup, lookup only sees the top layer of keys. So you can't nest a hash of parameters, you have to fully qualify each parameter name.

The docs have some examples: <https://puppet.com/docs/puppet/7/hiera_quick.html>

DeepinScreenshot_Alacritty_20220801145735.png

This is what I have so far, the class "installElasticsearch" installs Elasticsearch. But I would only like it run if it's not installed

If you're running Puppet Enterprise, there's a built-in fact that you can enable and reference, called `_puppet_inventory_1`

If you're running opensource, you'll have to write a custom fact of your own.

Or else you could come up with an `unless` clause for your `exec` resource.

for a couple of our in-house modules, we have code that looks like this:
``````

```$packages = ['my_package_name', 'my_package_alias']
unless any($facts.get('_puppet_inventory_1.packages', [])) |$p| {
  $p[0] in $packages
} {
  include mypackage::install
}```


that's a `hack`  :slightly_smiling_face: and only will work if `package_inventory_enabled` and only after second run

I do want the package installed, but I don't want the install script to run multiple times

then have a package resource to install the package and another resource to run the script only at the time the package is installed using a notify -&gt; or similar

ideally, install script will be part of the package, but, normally you would pick some file that identifies that installer already ran

right. the installer script can do a creates -&gt; or whatever to show that it's already run

```exec { '/install stuff':
  creates =&gt; '/path/to/installed/stuff'```

that way if file is already there, installer won't run twice

<@U03Q2UQLRC5> it will help if you change your thinking about Puppet. It doesn’t run tasks like “install elasticsearch”,  it maintains state like “ensure that elasticsearch is installed”

Not that I’m aware of.

The problem comes from the fact that knowing which classes are available means compiling/loading a directory environment full of code to parse the class names out of it.

At the most basic level of re-production, a similar outcome can be had from grepping through your Puppet code repositories or a deployed Puppet environment’s modulepath. But that’s not really all that useful long term.

I would think about swapping the way you go about it and move toward r10k or cd4pe which has you maintain a manifest of the modules you install so you can look at that to trace what classes exist

instead of going about trying to figure out what's there now

I wish I were a full-on developer.  I might’ve taken up the old Puppet dashboard and tried to keep it going.

In general, `puppet strings` might already do what you're looking for --- especially using the JSON output.

<@U11MDJNGZ> People are occasionally checking in classes to my control repo without any tests... I would like to make sure there is at least a basic `compile.with_all_deps` as I've frequently run into problems refactoring which aren't caught by tests.  I define the roles in an... unusual way... so I have unit tests which will catch untested roles.

<@U11MDJNGZ> That is a good idea... `puppet strings` is almost certainly parsing the files in a nominally not-dumb way.

<@U020LK7D0JU> I can get a class list out of puppetserver per env... but that's not really what I'm looking for.  I'm really looking to dump the list of classes in a single mod

Ah, if you're already using the PDK in your unit tests, then strings might be already available 

I pull in voxpupuli-test, so yep, it is there

Would <https://github.com/dylanratcliffe/onceover> be an option?

I didn't know about onceover. I will give it a look

at a glance, it sounds like it might be difficult to get it to work with my hiera setup

If the sensitive value is unwrapped inside an ERB you need to wrap the resulting string in a new Sensitive.

More context, I use the docker puppet module, and I need to pass and env var to a container. The module creates a script to run the container as a service with the right args. If I pass it as sensitive it fails replacing the actual key by `Sensitive [value redacted]`, so I have to unwrap it which then leaks in diff file the module use

Then it is up to the docker puppet module to do the right thing and support sensitive data.