jira tickets also all caps

in FOSS environments, r10k converts JIRA-1234 to JIRA_1234 and that works totally fine for the puppet agent

in PE it just seems to break task/plan support

The r10k configuration option that adjusts the git branch names to conform to Puppet standards is invalid_branches: "correct" and this can be set in /etc/puppetlabs/puppetserver/conf.d/code-manager.conf. Posting this because it took me a while to find where to set it. I don't know if this would also help with tasks/plans.

That's what I posted above

it's just not lowercase the environment name

it's just not lowercase the environment name

We're trying to start using stdlib 8.1.0 on PE 2019.8.12 and are getting this error:

2022-09-14T09:23:59.017-05:00 ERROR [qtp521455647-138959] [p.r.core] Internal Server Error: org.jruby.exceptions.LoadError: (LoadError) no such file to load -- puppet_x/stdlib

        at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:974)

any tips on getting stdlib 8.1 working on PE 2019?

I have 2019.8.11 with stdlib 8.4.0, haven't seen any issues

good to know

do you have compilers or anything? could be a filesync issue @hbui

do you have compilers or anything? could be a filesync issue @hbui

it's a single server

Hi Community, we have a very long running query in a customers puppet-db postgres installation, is there an option to configure it to run more frequently?:

DELETE FROM resource_params_cache WHERE NOT EXISTS ( SELECT * FROM catalog_resources cr WHERE cr.resource = resource_params_cache.resource);

Hi Community, we have a very long running query in a customers puppet-db postgres installation, is there an option to configure it to run more frequently?:

DELETE FROM resource_params_cache WHERE NOT EXISTS ( SELECT * FROM catalog_resources cr WHERE cr.resource = resource_params_cache.resource);

This query is blocking the database for 5+ hours on a regular basis

If you're deleting records regularly, are you also (auto)vacuuming the tables?

running this query every 30 or 60 minutes would be much more convenient

@Yorokobi yes we do

so the query is coming from https://github.com/puppetlabs/puppetdb/blob/6.22.1/src/puppetlabs/puppetdb/scf/storage.clj#L969-L976

so the query is coming from https://github.com/puppetlabs/puppetdb/blob/6.22.1/src/puppetlabs/puppetdb/scf/storage.clj#L969-L976

and we see 457 million deleted tuples in

resource_params

within a week

which is... a lot?

and the query runs for up to 6 hours and blocks some other inserts

It would really help a lot if it had a

LIMIT 1000000

or similar and would execute multiple times

in the meantime, • do we have an option to run it more often? • can someone explain why there is so data/is it supposed to be that much?

aha! https://github.com/puppetlabs/puppetdb/blob/b3d6d10555561657150fa70b6d1e609fba9c0eda/src/puppetlabs/puppetdb/cli/services.clj#L399

aha! https://github.com/puppetlabs/puppetdb/blob/b3d6d10555561657150fa70b6d1e609fba9c0eda/src/puppetlabs/puppetdb/cli/services.clj#L399

so I could curl the cmd api and trigger a manual delete for resource_params with the

other

key

I just dont yet understand how puppetdb schedules the garbage collection