This message was deleted.

This message was deleted.

quick question about scaling puppet CA, we have a large amount of certs, hitting the `puppet-ca/v1/certificate_status/`on puppetserver 6.4.0 is extremely slow and hangs with any concurrency. I’ve tried tuning GC/jruby instances etc., but expectedly has minimal impact since it looks like the server is loading the massive cert dir for each request? Are there any performance optimizations in subsequent versions…looks like the /clean endpoint has batching now in 7.x but glancing at the code it still looks like there aren’t optimizations for handling concurrency i.e. it’s still doing what PUT/DELETE do at the certificate_status endpoint for each host/are there ways of tuning puppetserver in a way to handle this load? Or is the only option reducing the size of this directory to control memory use? A PUT/DELETE cycle on 10 hosts takes 30s with concurrency and around 1min15s sequentially. I’m new to clojure so I may be mistaken in my review of the code, any help is appreciated, thanks!

message has been deleted

This message was deleted.

Do you want this just to be static? I.e we know which directories it creates in which case I think adding a template in https://github.com/puppetlabs/pdk-templates/tree/main/moduleroot and adding to https://github.com/puppetlabs/pdk-templates/blob/main/config_defaults.yml Should do it

message has been deleted

This message was deleted.

message has been deleted

This message was deleted.

In a normal Puppet run, that's definitely the case. But when running in noop, some things must be assumed when it comes to execs.

Assuming everything is always successful is not good behaviour, but it could at least be less bad behaviour

That's more to the point, I think. Might be helpful for the Puppet devs if you rephrase your ticket around that argument.

Also, here's an interesting bit about those qualifiers: https://github.com/puppetlabs/puppet/blob/7.21.0/lib/puppet/type/exec.rb#L13-L17 Puppet treats those as resource attributes that are used to determine the current state of the resource. So Puppet must execute those to determine whether the resource is in sync. Which makes sense in relation to how other resources are evaluated as being in sync or not.

Also, here's an interesting bit about those qualifiers: https://github.com/puppetlabs/puppet/blob/7.21.0/lib/puppet/type/exec.rb#L13-L17 Puppet treats those as resource properties that are used to determine the current state of the resource. So Puppet must execute those to determine whether the resource is in sync. Which makes sense in relation to how other resources are evaluated as being in sync or not.

And when running in noop mode, I believe it's the

sync

method that is just assumed to succeed and is never actually called.

Another thing to note here is that the behavior you're seeing is because the check to see whether a command's executable exists or not is called from inside the exec type's

sync

method: https://github.com/puppetlabs/puppet/blob/7.21.0/lib/puppet/type/exec.rb#L147 That

sync

method calls

provider.run

which ends up calling `checkexec(command)`: https://github.com/puppetlabs/puppet/blob/7.21.0/lib/puppet/provider/exec.rb#L44

checkexec

is where the check for existence happens: https://github.com/puppetlabs/puppet/blob/7.21.0/lib/puppet/provider/exec/posix.rb#L32-L33

This message was deleted.

I could run tests using rake but confused on builds, rake seems to only run tests benchmarks and generate docs

Seems like

bundle install

was the command. Thereafter ./bin/puppet works.

Seems like

bundle install

was the command. Thereafter

./bin/puppet

works (alternatively

sudo ./install.rb

copies them to /usr prefix).

message has been deleted

This message was deleted.

in a custom fact, I have this:

Facter.value(:networking)['fqdn']

Which was previously:

Facter.value(:fqdn)

The new structured fact seems to give me a

Caught recursion

error. Not sure what the difference here is between using these

This message was deleted.

This message was deleted.

that's what we do, eyaml key an yaml the cert

@vchepkov thanks again!

Heya folks: doing some ENC work as well as control-repo level site manifest work: ENC assigns which environment - Done. site manifest in environment :

node default {
  $pp_role = $trusted['extensions']['pp_role']
  include "role::${pp_role}"
}

even if I try on a compiler node to

puppet apply /etc/puppetlabs/code/environments/dev/manifests/site.pp

where ^ lives - I get

Error: Evaluation Error: Error while evaluating a Function Call, Could not find class ::role:: for

That trusted fact most definitely exists, I validated it via a facts api call and it was in the CSR. Ideas/thoughts? This approach has been mentioned over the years and appears to work (for those who have mentioned it) but I'm a bit lost. We use roles/profiles method extensively/exclusively.

extension_requests:
(redacted)
    pp_role: puppetcompiler

I should be assigned

role::puppetcompiler

based on interpolation