This message was deleted.

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

lol

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

@csharpsteen 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.

Is there a way to plug it back in?

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

If this is the way , suremandalorian

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

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

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

ahh you're talking about upgrades

yep

mhm

nope, they don't

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.

only puppet_enterprise ?

puppet_enterprise

is the majority consumer of that data. The

pe_infrastructure

and

pe_repo

modules also use it.

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

```- lost a level. (Karma: -109)

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

```- lost a level. (Karma: -110)

mhm interesting

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

😄