Is that triaged on a regular basis?

(related ticket: https://tickets.puppetlabs.com/browse/ENTERPRISE-1487)

It should be is my understanding…

Who do you normally liaise with at Puppet directly?

I would raise that with them…

honest answer? I (consultant) or the PE customer raise a ticket through zendesk, or we create issues in the different jira boards, usually people don't respond and then we escalate it through slack. and that's far away from a good workflow (hence I raised https://tickets.puppetlabs.com/browse/ENTERPRISE-1487 last friday)

honest answer? I (consultant) or the PE customer raise a ticket through zendesk, or we create issues in the different jira boards, usually people don't respond and then we escalate it through slack. and that's far away from a good workflow (hence I raised https://tickets.puppetlabs.com/browse/ENTERPRISE-1487 last friday)

OK - let me see if I can raise this internally to get feedback!

awesome, thanks!

Noticed errors in puppetserver.log

2022-11-21T13:54:12.903-05:00 ERROR [clojure-agent-send-off-pool-141473] [p.e.s.f.file-sync-storage-core] Failed to commit repo ':ssl-data', from staging dir '/etc/puppetlabs/puppet/ssl'.

This message was deleted.

do you have a replica?

yes, I do

This probably means file sync got tripped up on something. If your CA is in the old location

/etc/puppetlabs/puppet/ssl/ca

, then this means promoting your replica is going to result in a CA that’s only up to date since the last time it was able to sync. If your CA is in the new location (

/etc/puppetlabs/puppetserver/ca

I think it is), then it doesn’t matter so much as that’s handled separately with a different file sync, if I recall correctly. If it is file sync getting tripped up, usually deleting the file sync cache can fix that. https://puppet.com/docs/pe/2021.7/filesync_about.html#filesync_resetting If your CA is churning through a bunch of certs on a regular basis, this is more likely to happen. We’re currently looking at ways to make this better. Using file sync to sync the CA data isn’t really great, since we don’t care at all about the history.

This probably means file sync got tripped up on something. If your CA is in the old location

/etc/puppetlabs/puppet/ssl/ca

, then this means promoting your replica is going to result in a CA that’s only up to date since the last time it was able to sync. If your CA is in the new location (

/etc/puppetlabs/puppetserver/ca

I think it is), then it doesn’t matter so much as that’s handled separately with a different file sync, if I recall correctly. If it is file sync getting tripped up, usually deleting the file sync cache can fix that. https://puppet.com/docs/pe/2021.7/filesync_about.html#filesync_resetting If your CA is churning through a bunch of certs on a regular basis, this is more likely to happen. We’re currently looking at ways to make this better. Using file sync to sync the CA data isn’t really great, since we don’t care at all about the history, and files changing in the middle of JGit doing its thing tends to break it.

@Gareth McGrillan when the roadmap 2023 is ready, where could i view it? will there be a posting in the blog or something?

@Robert Waffen - apologies for the delay getting back - talking to folks here it’s all being finalised. So once I hear back I’ll reach back out and let you know once i get updated. Thanks for your patience! Gareth…

This message was deleted.

looks like "puppetcatalog.com" port 8140 is not reachable from your client. can you test with telnet or nmap if port 8140 and this dns name is reachable?

This message was deleted.

hey people, question about puppet-backup: It doesn't exclude

/opt/puppetlabs/bolt

. That's created by the bolt rpm. Now when we do a backup and restore it on a new server, the bolt dir is restored, but the package isn't installed (at least not by the package). That can cause some conflicts. I think puppet-backup should globally exclude: • /opt/puppetlabs/bin/bolt • /opt/puppetlabs/bin/bolt-inventory-pdb • /opt/puppetlabs/bolt

I am looking for Documentation for Puppet Console Node group variables but can't seem to find anything through google Search. Does anyone else use this and have any information about how it works?

@n3snah https://puppet.com/docs/pe/2019.8/grouping_and_classifying_nodes.html#set_variables

Variables set in the console become top-scope variables available to all Puppet manifests.

thanks @glee, Does this mean that the value will always be a string?

https://puppet.com/docs/pe/2019.8/grouping_and_classifying_nodes.html#tips_for_specifying_parameter_and_variable_values

Tips for specifying parameter and variable values

Parameters and variables can be structured as JSON. If they can't be parsed as JSON, they're treated as strings.

Parameters and variables can be specified using these data types and syntax:

• Strings (for example,

"centos"

)

◦ Variable-style syntax, which interpolates the result of referencing a fact (for example,

"I live at $ipaddress."

)

◦ Expression-style syntax, which interpolates the result of evaluating the embedded expression (for example,

${$os"release"}

)

> Note: Strings must be double-quoted, because single quotes aren't valid JSON.

> Tip: To enter a value in the console that contains a literal dollar sign, like a password hash — for example,

$1$nnkkFwEc$safFMXYaUVfKrDV4FLCm0/

— escape each dollar sign with a backslash to disable interpolation.

• Booleans (for example,

true

or

false

)

• Numbers (for example,

123

)

• Hashes (for example,

{"a": 1}

)

> Note: Hashes must use colons rather than hash rockets.

• Arrays (for example,

["1","2.3"]

)

see also: Variable-style syntax: https://puppet.com/docs/pe/2019.8/grouping_and_classifying_nodes.html#tips_for_specifying_parameter_and_variable_values-variable-syntax Expression-style syntax: https://puppet.com/docs/pe/2019.8/grouping_and_classifying_nodes.html#tips_for_specifying_parameter_and_variable_values-expression-syntax

This message was deleted.

Hello Community, I have a short question: Telegraf from Operational Dashboard performes the following HTTP GET request

https://<PUPPETSERVER_FQDN>:8140/status/v1/services?level=debug

This can be found in the puppetserver-access.log:

192.168.0.1 - - [19/Nov/2022:00:00:09 +0100] "GET /status/v1/services?level=debug HTTP/1.1" 200 63513 "-" "Ruby" 1589 - -
192.168.0.1 - - [19/Nov/2022:00:00:09 +0100] "POST /metrics/v2/read HTTP/1.1" 200 927 "-" "Ruby" 3 432 -

I have a few questions: 1. Does the GET request trigger/rely on the POST request? 2. If the GET request runs into a timeout, will the POST request run until it's finished? 3. How much of the data and duration of the GET request, is created by the POST request? Is there a way to track this or do I need to measure it myself?

This message was deleted.

telgraf uses a go http client

10.253.3.161 - - [29/Nov/20220910:00 +0000] “GET /status/v1/services?level=debug HTTP/1.1” 200 25664 “-” “Go-http-client/1.1” 356 - -