if one task is executed on 800 nodes is that not 800 tasks being run? I assume they wait in a queue that is managed via a setting.

someone else can execute another task ¯\_(ツ)_/¯

right and all would be managed via a central queue

could always let em ride to see what happens

https://puppet.com/docs/pe/2021.6/config_orchestration.html#configure_the_orchestrator_and_pe_orchestration_services Looks like 250 is the default

could write a plan that selects the nodes as a PQL query for != the version your upgrading to limited to 50 or 100 or whatever you’re number is

and then submit it back as a PR to the puppet_agent module

🙂

watch -n 300 bash upgrade_agents.sh

(No plan but the upgrade agents does use the pql query with a limit on it already). We are just upgrading without puppet otherwise puppet_agent in enforcing the version.

I am curious if anyone has word on when a new PE release (or LTS) might be due out? We're getting close to the time of the cycle for a new LTS release

would help with some internal planning if there was some forward announcements 🙂

@nwops be very careful when running large numbers of nodes in a single task. It will run only that task on those nodes until it has been completed. So anything else that comes up will queue behind it.

This message was deleted.

This message was deleted.

This is an upgrade from pe 2019.6.0. (Maybe even older). I’ll have the check out the CA files. There was old installers from 2016 present too 🙂

Is there a way to find catalog compilation failures via pql? Is it just to look for agents using cached catalog

This message was deleted.

https://github.com/puppetlabs/puppetlabs-pe_status_check/blob/main/lib/facter/agent_status_check.rb#L9 I don’t think 90 days is enough notice for some. Any way to make this configurable, or provide a fact that dumps expiration date?

This message was deleted.

We run puppet enterprise on AWS EC2 and we have it defined in Terraform so we can redeploy a new instance of puppet enterprise

I think we have a gap in terms of what you are doing and what I’d expect. So I would expect that you have a control-repo stored in git like our template here https://github.com/puppetlabs/control-repo Which includes a Puppetfile that defines the modules and versions of the modules you want. https://github.com/puppetlabs/control-repo/blob/production/Puppetfile However, I don’t think thats necessarily an issue. Your way should work can you share the error message you are getting around “an issue with one of our puppet modules failing due to a dependency issue” If that error is coming from the puppet module tool… it might not be a real error. The modules might not meet the declared dependencies of another module but that doesn’t necessarily mean your puppet code won’t work. So if you can force install all the modules and then you can still run your puppet code … that should all be fine.

Can I configure an agent to use multiple compilers in place of a LB?

yep

server_list

that is what I thought, I assumed it was only for compilers

nope. but it will hit first one on the list every time, unlike LB

Aye, there’s really no “balancing” there. It’s just a fail-over list.

A Load Balancer is the best choice for a compiler pool because it can make choices about load in a more sophisticated manner than “fail over” or “round robin”. Puppet Agent traffic in particular is a good fit for “least connections”.

The other strategies tend to pummel a server that falls behind by shoveling more load onto it.

The other strategies tend to pummel a server that falls behind by shoveling more load onto it.