FWIW this is the PR https://github.com/puppetlabs/puppet/pull/8902

Seems Fedora's support is lagging. F36 is out and the last supported version in PE is F34 😞

I think most people assume deferred functions follow normal puppet ordering/relationships and are surprised to find out it doesn't work that way. Also deferred function failures cause the entire run to fail, instead of only that resource and resources that depend on it.

But the lazy eval change will fix all of those things

@josh do you know if there are any new awesome ideas for pluginsyncing custom datatypes / any hopes for speeding up existing pluginsync? in my current env an agent spenda 50 to 70s just with pluginsync during each run (without any changes)

The F36 epic for open source is https://tickets.puppetlabs.com/browse/PA-4442. We recently migrated data centers and all of our platform addition work has been delayed. We're currently working on or will soon work on Windows 11, macOS 11 & 12 M1, Ubuntu 22.04, F36

@bastelfreak question for you--do you have many different platforms? I wonder if platform suitability detection would help reduce some of the time spent syncing or whether it would just trade sync runtime for platform detection runtime.

what kind of platforms do you mean?

eg, why sync powershell DSC providers to a linux node?

eg, why sync powershell DSC providers to a linux node?

I have around 45 envs with 950 nodes, mostly RHEL 7

ah

btw, RHEL9 is out in couple of weeks according to RedHat announcement

I have a many nodes that do not need the majority of the custom types/providers (all the enterprise modules)

btw, that was my issue as well, hence I created

windows_production

environments with module sets just for windows

About pluginsync, there's the segmentation issue @binford2k mentioned (controlling which agents get which plugins) and there's the "manage one file at a time" problem.

maybe the agent could just check the .ra10k-drploy.json from the server and if that matches the version on the agent it assumes its up2date

was it @bastelfreak who proposed the tarball pluginsync?

or get a digest file from puppetserver with all checksums

There are lots of possible optimizations for the latter problem.

@binford2k no, PE does the .tar.gz. there is a ticket that suggests implementing the .tar support in puppetserver

Did you know that each agent pluginsync request causes puppetserver to calculate file checksums for every possible pluginsync-able file?

@binford2k https://tickets.puppetlabs.com/browse/SERVER-2539

@josh lol

And then puppetserver does the same thing again for the next agent pluginsync request

how smart of you to implement something with so much room of easy improvements!

:D

indeed sounds like a rather simple fix? the puppetserver knows the requested file.

We've talked about precalculating all of the file metadata & checksums during a code deploy for an environment, like how you can run

puppet resource generate

to generate the pcore resource types.