I wouldn't think so

I'm actually not sure what notifying a class actually does

I'm mostly certain notifying a class containing a resource will notify the resources. but not resources from classes included in that class.

but you should test to verify

yeah that's why the convention is like this https://github.com/voxpupuli/puppet-nginx/blob/10162d14597d58e09c2f2241808ea06ed0754713/manifests/init.pp#L261 a change to the config notifies the service and restarts or reloads it

yeah that's why the convention is like this https://github.com/voxpupuli/puppet-nginx/blob/10162d14597d58e09c2f2241808ea06ed0754713/manifests/init.pp#L261 a change to the config notifies the service and restarts or reloads it

that isn't notification though, it's ordering?

~>

is notifying https://www.puppet.com/docs/puppet/7/lang_relationships.html#lang_rel_chaining_arrows

and today I learned

That must've been fixed at some point. I know we ran into issues in the past where class notifications didn't automatically mean resources within it.

It’s more or less always passed the notify into the class

but not into classes contained by that class

since at least 2009 🙂

I wonder if anyone can help to solve the problem in crayfishx-purge module The module correctly identifies unmanaged cron resources and reports them being deleted https://github.com/crayfishx/puppet-purge/blob/master/lib/puppet/type/purge.rb#L194

See the

crayfishx-purge

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

I wonder if anyone can help to solve the problem in crayfishx-purge module The module correctly identifies unmanaged cron resources and reports them being deleted https://github.com/crayfishx/puppet-purge/blob/master/lib/puppet/type/purge.rb#L194

But, it doesn't delete them. The reason, I believe, is that object doesn't have proper user/target fields set

and I am not sure, why.

puppet resource cron

shows them properly

@crayfishx ^

@vchepkov rings a bell… I think this is a bug in the cron code. When I tried to purge all crontabs in a Bolt plan for decomissionning nodes, I had to workaround a similar issue, crontab where not removed, and I had to do a workaround: https://github.com/opus-codium/puppet-commission/blob/master/files/clean-cron-jobs.sh

@vchepkov rings a bell… I think this is a bug in the cron code. When I tried to purge all crontabs in a Bolt plan for decomissionning nodes, I had to workaround a similar issue, crontab where not removed: https://github.com/opus-codium/puppet-commission/blob/master/files/clean-cron-jobs.sh

On the other hand

puppet resource cron

also list unmanaged crontabs, so maybe it is not a bug, but a wise choice? I have not dig into this…

@vchepkov rings a bell… I think this is a bug in the cron code. When I tried to purge all crontabs in a Bolt plan for decomissionning nodes, I had to workaround a similar issue, crontab where not removed, and I had to do a workaround: https://github.com/opus-codium/puppet-commission/blob/master/files/clean-cron-jobs.sh

hmm, cron resource is now in a forge module, maybe I should open a case there too

*_core are included in the AIO by default

I believe installed module overrides provider in agent

Can someone tell me, does Puppet always try to evaluate an Exec command before it evaluates the Requires parameters?

I don't know why these two execs behave differently, given they both Require the Package[postgresql14-server] to provide the exec commands

Postgresql_server/Package[postgresql14-server]/ensure: current_value 'purged', should be 'present' (noop) (corrective)
Postgresql_server/Exec[postgresql-initdb]/returns: current_value 'notrun', should be ['0'] (noop) (corrective)
Postgresql_database/Exec[create-seiscomp-db]: Could not evaluate: Could not find command '/usr/bin/psql'

Correction, the error is caused by using

Unless

on the Exec, getting evaluated before

Requires

This is in 6.28.0