hey Jerry the target will be the primary where it will need to run the Puppet certificate commands against your list of nodes. It actually runs a check to make sure you are on the Primary https://github.com/puppetlabs/support-tasks/blob/main/tasks/st0317b_purge_node.rb#L17-L23

sorry I clicked wrong task https://github.com/puppetlabs/support-tasks/blob/main/tasks/st0317a_clean_cert.rb#L22-L30

sorry I clicked wrong variant of the task heres the clean https://github.com/puppetlabs/support-tasks/blob/main/tasks/st0317a_clean_cert.rb#L22-L30

I am wanting HA, but not sure how that work with only a single orchestrator service, but we have two sides from every data center that go primary and then a fail over, but we use different proxy for primary and failover and it can be different depending on country and dc. This issue I am finding when fail over cant reach primary due to internal issue that might happen, even though agents are connected to dr, primary loses them or the start trying to hit primary from dr side and fail. So when the proxy comes back on the round robin it might go through primary but try to hit failover site.

ah just the url list then?

The PE Orchestrator does not have a HA feature. PE DR provides HA for

puppet

agent runs, using existing code and classification. Everything else (ca operations, code deployment, classification changes, orchestration, etc.) is in a "warm standby" mode that becomes writable if the Replica is promoted to Primary.

There's no supported PE architecture where the pxp-agents can end up connected to a DR replica prior to promotion --- because the service does not run prior to promotion.

Even the DR replica kind of not the issue, it more needing to keep it on one side until something happen and it knows to try the other side, but with two proxy each agent needs, it might be difficult to point correctly where it should go, since agent/pcp round robin.

This message was deleted.

This message was deleted.

This message was deleted.

Hi Guys, hopefully one of you can shed some light on an issue I am having on a clients system, I am looking to perform some upgrades from puppet 2018.1.5 , but when trying to run a puppet agent -t on the replica server we are faced with . All other agents are ok and run their puppet agent -t without issues. It is the same without --noop Is there any value in regenerating certificates in this case? or any other ideas what could be causing this? Many thanks

Hi Guys, hopefully one of you can shed some light on an issue I am having on a clients system, I am looking to perform some upgrades from puppet 2018.1.5 , but when trying to run a puppet agent -t on the replica server we are faced with . All other agents are ok and run their puppet agent -t without issues. It is the same without --noop Is there any value in regenerating certificates in this case? or any other ideas what could be causing this? Many thanks

your puppet.conf seems have wrong configuration, check your server_list, it takes precedence

If I check the server_list values on the replica server which is failing.. it has this.. [agent] server_list = DNSforprimaryMaster8140,DNSforSelf8140 hope that makes sense.

it does, but that's not what agent sees

Which

puppet --version

is this? There was a bug a while ago where if no entry in

server_list

was reachable, the

hostname:port

would end up set to

nil:0

.

Ah, 2018.1.5 -- so Puppet 5. That might be old enough.

Yup, https://tickets.puppetlabs.com/browse/PUP-8967. Fixed in 2018.1.9

oh wow yep sounds about right.. I will check that bug report! thx

it is indeed puppet v 5

The addresses in server_list are in fact reachable, we have tried with ping / telnet and it is all working. just the puppet agent -t comes back with that error.

The addresses in server_list are in fact reachable, we have tried with ping / telnet and it is all working. just the puppet agent -t comes back with that error.

Have anyone noticed puppetlabs/puppet_operational_dashboards flips telegraf settings most of the time? from what I can tell it swap primary/replica in configuration files

for example, in

puppetserver_metrics.conf

urls order changes for primary/replica

This message was deleted.

Hey, we're in the process of cleaning up legacy facts and functions for a customer, to reduce some noise in the puppetserver.log. The puppet-agent module uses one of those functions https://github.com/puppetlabs/puppetlabs-puppet_agent/pull/628 . Can this be reviewed?

Hey, we're in the process of cleaning up legacy facts and functions for a customer, to reduce some noise in the puppetserver.log. The puppet-agent module uses one of those functions https://github.com/puppetlabs/puppetlabs-puppet_agent/pull/628 . Can this be reviewed?

I've fed in these sites lacking updates, we're speaking to our marketing/communication team, I am using my usual combo of slack reminders and I will get back here on this