Puppet Community

Editing scheduled tasks is boss (scheduled plans should get this soon too)

stopping in-progress tasks &amp; plans was a long standing request - glad we got to those

there’s also a new `pending` job state that I think will help some folks out

Along with timeout limits for tasks &amp; plans

what does stopping the task do? Will it actually _kill_ the process on the target node?

:the_more_you_know: Next up is _:teacher:Puppet Core Team_ in <https://www.timeanddate.com/worldclock/converter.html?iso=20230131T180000&amp;p1=202&amp;p2=179&amp;p3=919&amp;p4=307&amp;p5=3332&amp;p6=236&amp;p7=240|115 hours>

I believe it uses  `"force": true` when it hits the `command/stop` endpoint <https://www.puppet.com/docs/pe/2023.0/orchestrator_api_commands_endpoint.html#orchestrator_api_post_command_stop>

there are some edge cases around that, but it should kill it

OK, that’s a wrap for today - we’ll be back in a couple of weeks. Y’all be good to yourselves.

:fry_dancing: _:teacher:Puppet Core Team_ is about to start up in 15 minutes

Hi folks, Have a question about open source puppet, ask away!

I see only puppet 7? <https://nightlies.puppet.com/apt/pool/bullseye/puppet8-nightly/p/puppet-agent/index.html>

Or are they not versioned differently yet?

The version string `7.21.0.X.g&lt;SHA&gt;` is X number of commits past the 7.21.0 tag

Also I wanted to mention we've started shipping puppet-agent 8 nightly builds for Redhat, Fedora, SLES, Debian, Ubuntu and macOS to <https://nightlies.puppet.com/>

I stepped on this ticket <https://tickets.puppetlabs.com/browse/PUP-11685> while migrating to puppet 7. Is there a good way to find which fact causes issue ?

the error message is somewhat misleading, since actual fact count is low

it's just, I presume, some facts are too deep?

If we count paths by doing a depth-first walk of the fact hash, we could probably track the path count under each top-level fact and print out the "top 10" if the total count is larger than the threshold.

Ah sorry, I meant to say I don't know of a good way given the current implementation. But what you're saying sounds great. The counting starts here <https://github.com/puppetlabs/puppet/blob/f4fbaaac5b21731929e76a7218b3f735ef41cd15/lib/puppet/configurer.rb#L211>

Could you add some details to the ticket about how systemd v4 exposes the issue? Anything to help reproduce would be very useful.

but basically, they added a lot of data inside a udev fact

I blocklisted the fact, because that was a recent change and I knew where to look. switching from puppet6 to puppet7 just brings the problem to light with no clear path, how to address it

from what I see in configuration parameter names, it's a soft limit

you can still use the fact with v4.0.1 from puppet/systemd

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

ah I see <https://github.com/voxpupuli/puppet-systemd/issues/314>

It’s a bug.  I’ve seen a lot of chatter about it here on the channels

If we count paths by doing a depth-first walk of the fact hash, we could probably track the path count per top-level fact and print out the "top 10" if the total count is larger than the threshold.