Puppet Community

(if we do an SBOM and sign each file instead, then we've got more leeway)

at vox pupuli we considered changing the .pmtignore to include only what's required and I could implement that in pdk-templates as well. I don't want the forge to modify releases

but it would be nice if the forge could flag releases that contain unneeded files and if r10k/code-manager had an option to filter out all not-needed files

it is kind of funny that Puppet is so configurable, being written in Ruby where the leading framework's motto is "convention not configuration"

There's actually an important bit of PE configuration behavior that depends on the fact we didn't do that :smiling-face-but-you-can-see-pain-in-their-eyes:

The `puppet_enterpise` module defines its datadir to be `/etc/puppetlabs/enterprise/conf.d/` so that re-configuration after restore of a backup, or during a classifier outage will mostly Do The Right Thing™ instead of shifting the entire PE install to out-of-box-defaults which is, if nothing else, a great way to slam a performance issue on top of whatever problem you were trying to solve :lolsob:

But, pointing to an absolute path is a lesser evil compared to relative paths or symlinks that lead to hoisting yourself on a petard of your own cleverness.

I was always wanted to ask, why installer doesn't honor user's hiera, maybe I miss some step? I observe installer revert custom setting and then puppet agent puts them back

I understand that maybe hierarchy is a challenge, but I keep pe settings in common.yaml

<@U11MDJNGZ> tangent: did you know that "petard" is a small bomb and the word etymology is latin for "to fart"?

The installer did have a tap into `common.yaml`, but I think that has become less useful recently as `puppet infra configure` sandboxes its `environmentpath` to `/opt/puppetlabs/server/data/environments/` and uses the `enterprise` environment --- as a firebreak between sensitive operations like upgrade and the infinite combinations of user module behavior that acceptance tests can't guard against.

In general, the usefulness of user Hiera is debatable since the directories don't exist before installation and are some form of circular dependency after.

or we have to deploy pe.conf instead somehow?

some services are not properly restarted when they are 'reverted' for example -
```puppet_enterprise::profile::plan_executor::versioned_deploys```

you can provide your own pe.conf for the pe-installer/peadm

The hierarchy used by `puppet infra configure` is defined in `/etc/puppetlabs/enterprise/hiera.yaml`, but I wouldn't recommend modifying it as one of two things is likely to happen depending on whether it is marked as a config file in the packages:

• The file gets overwritten on upgrade and unexpected things happen because customized data sources are no longer pulled in.
• The file _does not_ get overwritten on upgrade and unexpected things happen because updated defaults are no longer pulled in.

and if you provide a pe.conf the data will be added to the classifier and you won't be able to override it in hiera. so I usually provide a minimal config that just disables metrics/update check

then configure code manager, do code deploy, configure the rest via data in hiera

enterprise/hiera.yaml does reference common.yaml. but probably it gets ignored because environment is not what normal is

```  - name: "Common data from Hiera3 user hieradata"
    datadir: "/etc/puppetlabs/code/environments/%{environment}/hieradata"
    data_hash: yaml_data
    path: "common.yaml"

  - name: "Common data from Hiera5 user data"
    datadir: "/etc/puppetlabs/code/environments/%{environment}/data"
    data_hash: yaml_data
    path: "common.yaml"```

do you deploy your code before running the installer?

not sure what do you mean? installer is also executed during upgrades, so code is already there

before you said that I thought our upgrades honoured our hiera data, but now I'm not so sure anymore

`sudo crontab -l` should show `puppet infra recover_configuration` running on a schedule. That tool looks at PuppetDB and tries to determine if any `puppet_enterprise` parameters are being set via Classifier or user Hiera data. It then writes those values back to `/etc/puppetlabs/enterprise/conf.d/user_data.conf` and `enterprise/conf.d/nodes/*.conf` in the case of settings that appear to be different for compilers vs. primary vs. replica vs. database.

`puppet infra configure` also runs that same configuration recovery to sync `enterprise/conf.d/` up before making changes. The `--no-recover` flag is commonly used to skip this step in situations where PuppetDB is not responding.

`puppet_enterprise` is the majority consumer of that data. The `pe_infrastructure` and `pe_repo` modules also use it.

Looks like those other two may specifically only care about `pe.conf`. `pe_infrastructure` is mostly active during first install, not sure why `pe_repo` ignores the other data files --- likely just an oversight.

I observed quite a few changing back and forward - for example
```--- /etc/puppetlabs/nginx/conf.d/proxy.conf	2023-02-16 09:48:18.801727023 -0500
+++ /etc/puppetlabs/nginx/conf.d/proxy.conf.augnew	2023-05-04 19:10:35.327820741 -0400
@@ -17,7 +17,7 @@
 ssl_session_cache shared:SSL:50m;
 location /
 {
-proxy_pass <http://127.0.0.1:4430>;
+proxy_pass <http://localhost:4430>;```
I think the process misses some hiera
that one is driven by puppet_enterprise::plaintext_address, for example and it's not extracted to conf.d

This goes back and forward
```--- /etc/puppetlabs/r10k/r10k.yaml      2023-02-04 09:46:53.577921459 -0500
+++ /tmp/puppet-file20230504-3697032-knu4j4     2023-05-04 19:08:34.304876302 -0400
@@ -1,8 +1,8 @@
 ---
-cachedir: /opt/puppetlabs/server/data/puppetserver/r10k
+cachedir: /opt/puppetlabs/puppet/cache/r10k
 sources:
   puppet:
-    basedir: /etc/puppetlabs/code/environments
+    basedir: /opt/puppetlabs/server/data/environments```

I just reboot server now after upgrade is done :slightly_smiling_face: ¯\_(ツ)_/¯

and to heck with PE needing it there :loldread:

<@U1PC2RAH0> so you're proposing that the Forge not filter out disallowed content -- it's all included in the tarball. And that r10k / puppet module should filter out unknown/irrelevant data on install. (which means that pmt could have a --no-filter flag so people could get all the content, should they want it.)

yes. I don't want the forge to modify the upload because I also want gpg sigs for modules

but the forge should print a warning that the module doesn't follow best practices and includes unneeded files

:letsplay: Next up is _Content and Tooling_ in <https://www.timeanddate.com/worldclock/converter.html?iso=20230530T140000&amp;p1=202&amp;p2=179&amp;p3=919&amp;p4=307&amp;p5=3332&amp;p6=236&amp;p7=240|115 hours>

:the_more_you_know: _Content and Tooling_ is about to start up in 15 minutes

Hey everyone :wave: the CAT :puppet: team will be around for the next hour or so to answer any questions :slightly_smiling_face:

<https://github.com/puppetlabs/pdk-templates/blob/main/README.md#rakefile>
See `linter_options` here

<https://github.com/puppetlabs/pdk-templates/blob/main/moduleroot/.puppet-lint.rc.erb> also

I’d start here at least :slightly_smiling_face:

but right now my understanding is that is the only way to do it ^^

if the parameter_documentation / parameter_types checks are enabled by default I dont mind it

<http://puppet-lint.com/checks/documentation/>

I jsut wasn't sure. at vox pupuli we made it opt-in

afaik there is no “method to the madness” and there are some checks that are disabled in spec_helper (i think)

<https://github.com/puppetlabs/pdk-templates/blob/main/moduleroot/Rakefile.erb#L65>

and <https://github.com/puppetlabs/pdk-templates/blob/ab2bd48faf3a03796be8dee47284651b8e0cb428/config_defaults.yml#L63>

<https://github.com/voxpupuli/modulesync_config/blob/master/config_defaults.yml#L43> we disabled the two checks I mentioned because they require some work on our modules. more and more of our modules opt-in to them. We render that to Rakefile and .puppet-lint.rc

ah ok looks like we have inherited that part from module_sync then

<https://github.com/voxpupuli/modulesync_config/blob/master/moduleroot/.puppet-lint.rc.erb> +ah no, only to the puppet-lint.rc. The rake tasks reads that by default

or to rephrase: are the parameter_documentation / parameter_types checks enabled by default or can they be enabled?

Thats all for this week :wave: :cat-dance: see you all next Tuesday

:businessparrot: Next up is _:teacher:PE Console_ in <https://www.timeanddate.com/worldclock/converter.html?iso=20230601T210000&amp;p1=202&amp;p2=179&amp;p3=919&amp;p4=307&amp;p5=3332&amp;p6=236&amp;p7=240|54 hours>

Hello, everyone.  Is there puppet7 agent for RHEL 9 aarch64? Not seeing it under <https://yum.puppet.com/puppet7/el/9/index.html>.  Thank you.

x86_64 is for Intel/AMD processors, not ARM (aarch64).

well, in the meantime, seems like puppet7 agent for RHEL8 works on RHEL9.