Jira (PDB-5599) Remove catalog resources pg_trgm index on file path
Title: Message Title Charlie Sharpsteen commented on PDB-5599 Re: Remove catalog resources pg_trgm index on file path And to give a concrete example of the degree to which tri-gram indexes amplify writes, from the Postgres docs: Each word is considered to have two spaces prefixed and one space suffixed when determining the set of trigrams contained in the string. For example, the set of trigrams in the string “cat” is “ c”, “ ca”, “cat”, and “at ”. https://www.postgresql.org/docs/14/pgtrgm.html A file named the_quick_brown_fox would result in 19 tri-grams that need to be written out as part of the row update: t th the he_ e_q _qu qui uic ick ck_ k_b _br
Jira (PDB-5599) Remove catalog resources pg_trgm index on file path
Title: Message Title Charlie Sharpsteen commented on PDB-5599 Re: Remove catalog resources pg_trgm index on file path As noted in PE-34880, any operation that causes mass updates to agent catalogs will create a peak load that is then amplified by this GIN index and can bring database performance to its knees. Add Comment This message was sent by Atlassian Jira (v8.20.21#820021-sha1:38274c8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.481564.1676566129000.2259.1685036760193%40Atlassian.JIRA.
Jira (PDB-5599) Remove catalog resources pg_trgm index on file path
Title: Message Title Charlie Sharpsteen commented on PDB-5599 Re: Remove catalog resources pg_trgm index on file path This index was originally added in PDB-4640 to support CD4PE Impact Analysis. Impact analysis needs to look at a git diff with modifications to a file name like mod_name/manifests/foo.pp and determine all nodes in PuppetDB with catalogs that might have resources defined in the modified file. This used to be done via a regex match against the file field of the resources entity and PDB-4640 added a GIN tri-gram index to help speed those matches up. However, the regex match solution eventually proved inadequate even with the index and CD4PE switched (CDPE-4869) to re-constructing the resource type from the modified files (e.g. mod_name/manifests/foo.pp is either a Mod_name::Foo defined type or a Class['Mod_name::Foo']. Regex matching is still used in the very rare edge case of modifications to a site manifest. That leaves the catalog_resources_file_trgm index behind as unused in almost all PE installations. This type of index is extremely expensive for the database to maintain, resulting in several negative impacts that get worse as the size of a PE installation scales up: On row updates, regular Postgres B-Tree indexes impose a tax of one additional write to store a copy of the indexed value. GIN indexes require multiple additional writes. In the case of a GIN tri-gram, the indexed value is split into groupings of three characters (tri-grams) and an index update is written for each grouping. For a long value like a file path, this can translate into dozens or hundreds of extra writes per row update. The write amplification results in a lot of disk space being used. The catalog_resources_file_trgm index appears frequently in the top consumers of disk space for a PuppetDB database — the previous comment gives an example of over one third of the total PuppetDB database size being bound up in this index. Even when not used by queries, GIN indexes have to be updated with each new row and maintained by autovacuum and autoanalyze. Due to their amplified writes and large on-disk size, this results in significant amounts of additional read and write I/O. In the case of autovacuum and autoanalyze, Postgres has a global "budget" for I/O performed as part of maintenance that controlled by the autovacuum_vacuum_cost_limit setting. A maintenance process that is working on catalog_resources_file_trgm can easily burn this entire budget — which forces all other maintenance workers to sleep for a period of time until the budget refills. This means the the existance of a large, unused index increases the time required to maintain every other table and index in the database server and results in the entire dataset being organized less efficiently. So, to summarize: GIN indexes are massively expensive, to the point of requiring upkeep that is disproportionate to the utility they provide when covering large sets of long strings. Often, re-factoring application logic to reduce the use of pattern matching is truly the cheaper option. catalog_resources_file_trgm is a specific index discussed in this ticket, but
Jira (PUP-5600) Add "none" parameter to catalog_cache_terminus configuration reference
Title: Message Title Charlie Sharpsteen updated an issue Puppet / PUP-5600 Add "none" parameter to catalog_cache_terminus configuration reference Change By: Charlie Sharpsteen Issue:There is currently no "none' parameter to pass the catalog_cache_terminus reference. If you want your --noop run not to trigger changes from a cache catalog as in (PUP-3077) you currently have to pass an invalid string:puppet agent -t --noop --catalog_cache_terminus= `` '' Request:It would be nice to have the a "none" option similar to how you can specify "none" to disable data bindings in hiera (https://docs.puppetlabs.com/hiera/3.0/puppet.html#to-disable) Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit
Jira (PUP-5600) Add "none" parameter to catalog_cache_terminus configuration reference
Title: Message Title Charlie Sharpsteen commented on PUP-5600 Re: Add "none" parameter to catalog_cache_terminus configuration reference Re-opening this one as we just had another use case for skipping cache updates come in: Puppet agents that normally run with use_cached_catalog = true set in `puppet.conf`, but where Operators use Bolt tasks to roll out targeted updates by combining -no-use_cached_catalog with options like -tags that filter which parts of an upgrade catalog are enforced. The problem is that -no-use_cached_catalog updates the cache, and the next regular scheduled daemon run enforces any remaining changes that were not filtered by -tags. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.109309.1449873923000.1306.1677525480029%40Atlassian.JIRA.
Jira (PUP-5600) Add "none" parameter to catalog_cache_terminus configuration reference
Title: Message Title Charlie Sharpsteen updated an issue Puppet / PUP-5600 Add "none" parameter to catalog_cache_terminus configuration reference Change By: Charlie Sharpsteen Affects Version/s: PUP 6.28.0 Affects Version/s: PUP 7.23.0 Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.109309.1449873923000.1307.1677525480052%40Atlassian.JIRA.
Jira (PDB-4937) Add a default statement timeout to user queries
Title: Message Title Charlie Sharpsteen commented on PDB-4937 Re: Add a default statement timeout to user queries Re-opening this one. We've got a ticket where a user is reporting queries that persist for 1 day or longer and end up blocking other PuppetDB activities by holding locks. The root cause of this behavior is likely some other issue, but a default timeout for queries is a first line of defense that would help to blunt the impact. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.375530.1603302604000.45217.1665516900284%40Atlassian.JIRA.
Jira (PDB-4937) Add a default statement timeout to user queries
Title: Message Title Charlie Sharpsteen updated an issue PuppetDB / PDB-4937 Add a default statement timeout to user queries Change By: Charlie Sharpsteen Zendesk Ticket Count: 1 Zendesk Ticket IDs: 49787 Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.375530.1603302604000.45212.1665516780225%40Atlassian.JIRA.
Jira (PUP-4429) Puppet command line tools accept partial matches for flags without altering behavior
Title: Message Title Charlie Sharpsteen updated an issue Puppet / PUP-4429 Puppet command line tools accept partial matches for flags without altering behavior Change By: Charlie Sharpsteen Affects Version/s: PUP 7.18.0 Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.76253.1429220104000.24030.1661537340054%40Atlassian.JIRA.
Jira (PUP-4429) Puppet command line tools accept partial matches for flags without altering behavior
Title: Message Title Charlie Sharpsteen commented on PUP-4429 Re: Puppet command line tools accept partial matches for flags without altering behavior Still an issue with Puppet 7.18.0. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.76253.1429220104000.24029.1661537340047%40Atlassian.JIRA.
Jira (PUP-11451) Make collecting exported resources optional
Title: Message Title Charlie Sharpsteen commented on PUP-11451 Re: Make collecting exported resources optional After taking a second look at this, I think the goal can already be accomplished without introducing a new setting. Exported resource collection is implemented via the Indirector subsystem using the Resource terminus. Configuration of this subsystem can be specified via the routes.yaml file. So, disabling exported resources is just a matter of creating a new "none" terminus for Resource that returns an empty array for search operations: # cat /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/resource/none.rb require 'puppet/indirector/none' # A none terminus type, meant to always return nil class Puppet::Resource::None < Puppet::Indirector::None def find(request) return nil end def search(request) return Array.new end
Jira (PUP-9474) Automatic parameter lookup times should show up in profiler metrics
Title: Message Title Charlie Sharpsteen commented on PUP-9474 Re: Automatic parameter lookup times should show up in profiler metrics Re-opening. Hiera lookups are a very performance-sensitive component of catalog compilation and latencies can be highly variable, especially if a backend communicates with an external service instead of reading and caching files from disk. Being able to track the performance of Hiera via metrics is the difference between solving a ticket in an afternoon or over the course of days with heavy amounts of profiling data. Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.294729.1549307898000.31152.1646759100224%40Atlassian.JIRA.
Jira (PUP-11451) Make collecting exported resources optional
Title: Message Title Charlie Sharpsteen commented on PUP-11451 Re: Make collecting exported resources optional This does seem like a simple settings addition + modification of the resource collector behavior. But, I wonder if adding a setting that causes exported resources to be silently ignored is really the right solution because it would be confusing to debug if someone missed the release note. If exported resource collections are disallowed for some reason, it seems better to remove their use from the Puppet codebase and use lint checks to prohibit any re-introduction. Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.434328.1643983687000.26849.1646179680041%40Atlassian.JIRA.
Jira (PUP-7136) Enable the tracing of lookup calls on a per-node basis
Title: Message Title
Charlie Sharpsteen commented on PUP-7136
Re: Enable the tracing of lookup calls on a per-node basis
Alright, Hiera lookups can indeed be explained on a per-node basis via the log_level support added to /puppet/v4/catalog in SERVER-2520:
# curl -ksS \
-H "Content-Type: application/json" \
--cert $(puppet config print hostcert) \
--key $(puppet config print hostprivkey) \
https://localhost:8140/puppet/v4/catalog \
--data-binary @- <
| jq -r '.logs[]|.message|select(.|test("^Lookup of"))'
{"certname": "$(puppet config print certname)",
"persistence": {"facts": false,
"catalog": false},
"environment": "production",
"options": {"capture_logs": true,
"log_level": "debug"}}
Jira (PUP-7136) Enable the tracing of lookup calls on a per-node basis
Title: Message Title Charlie Sharpsteen commented on PUP-7136 Re: Enable the tracing of lookup calls on a per-node basis The ability to set the a per-request log_level on the /v4/catalog API might resolve this by making it easy to get the explain logs for just one node — I'll look into it. Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.172347.1485459833000.21543.1645557960238%40Atlassian.JIRA.
Jira (PUP-7136) Enable the tracing of lookup calls on a per-node basis
Title: Message Title Charlie Sharpsteen assigned an issue to Charlie Sharpsteen Puppet / PUP-7136 Enable the tracing of lookup calls on a per-node basis Change By: Charlie Sharpsteen Assignee: Charlie Sharpsteen Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.172347.1485459833000.21544.1645557960284%40Atlassian.JIRA.
Jira (PUP-7136) Enable the tracing of lookup calls on a per-node basis
Title: Message Title Charlie Sharpsteen commented on PUP-7136 Re: Enable the tracing of lookup calls on a per-node basis Re-opening. "Why is my node not finding the Hiera data I expect?" is still a very common and time-consuming troubleshooting query. Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.172347.1485459833000.21525.1645557360093%40Atlassian.JIRA.
Jira (PDB-5364) Enabling log-queries in 7.7.1 causes JSON serialization failures
Title: Message Title Charlie Sharpsteen commented on PDB-5364 Re: Enabling log-queries in 7.7.1 causes JSON serialization failures Looks like PDB-5259 fixed this in passing by adding an encoder for PgArray objects along with performance optimizations. Should be present in 6.20.0 and 7.9.0. Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.423245.163664995.13082.169760031%40Atlassian.JIRA.
Jira (PDB-5364) Enabling log-queries in 7.7.1 causes JSON serialization failures
Title: Message Title Charlie Sharpsteen commented on PDB-5364 Re: Enabling log-queries in 7.7.1 causes JSON serialization failures This issue also affects PuppetDB 6.19.1 in PE 2019.8.9. Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.423245.163664995.13055.168020057%40Atlassian.JIRA.
Jira (PDB-5364) Enabling log-queries in 7.7.1 causes JSON serialization failures
Title: Message Title Charlie Sharpsteen updated an issue PuppetDB / PDB-5364 Enabling log-queries in 7.7.1 causes JSON serialization failures Change By: Charlie Sharpsteen Affects Version/s: PDB 6.19.1 Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.423245.163664995.13054.167960103%40Atlassian.JIRA.
Jira (PUP-11319) Updated puppet gem and rspec-puppet Failures
Title: Message Title Charlie Sharpsteen updated an issue Puppet / PUP-11319 Updated puppet gem and rspec-puppet Failures Change By: Charlie Sharpsteen Affects Version/s: PUP 6.25.0 Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.419463.1634134581000.4387.1643653560185%40Atlassian.JIRA.
Jira (PUP-11319) Updated puppet gem and rspec-puppet Failures
Title: Message Title
Charlie Sharpsteen commented on PUP-11319
Re: Updated puppet gem and rspec-puppet Failures
This also affects Puppet 6.25.0 and is triggered by the default spec test provided by pdk new class. The issue is not specific to service, any resource type that is paired with providers will trigger this issue (e.g. notify is fine since it is a bare type).
$ pdk --version
2.3.0
pdk test unit --puppet-version 6.x
pdk (INFO): Using Ruby 2.5.9
pdk (INFO): Using Puppet 6.25.0
[✔] Preparing to run the unit tests.
/opt/puppetlabs/pdk/private/ruby/2.5.9/bin/ruby -I/opt/puppetlabs/pdk/share/cache/ruby/2.5.0/gems/rspec-core-3.10.1/lib:/opt/puppetlabs/pdk/share/cache/ruby/2.5.0/gems/rspec-support-3.10.3/lib /opt/puppetlabs/pdk/share/cache/ruby/2.5.0/gems/rspec-core-3.10.1/exe/rspec --pattern spec/\{aliases,classes,defines,functions,hosts,integration,plans,tasks,type_aliases,types,unit\}/\*\*/\*_spec.rb --format progress
Run options: exclude {:bolt=>true}
FF
Failures:
Jira (PUP-7520) Puppet profiling timers do not use a monotonic clock
Title: Message Title Charlie Sharpsteen commented on PUP-7520 Re: Puppet profiling timers do not use a monotonic clock Re-opening this one as inaccurate profiling results are far, far worse than not having any profiler functionality. This condition is uncommon, but Puppet does manage the sort of system configuration that can cause clock jumps. This change probably doesn't even need to wait for a semver major like Puppet 8 at this point as Ruby 2.1 and older are deeply end of life. Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.190330.1494519442000.10911.1640708400049%40Atlassian.JIRA.
Jira (PDB-5282) Empty certname in PuppetDB command data results in NullPointerException during startup
Title: Message Title Charlie Sharpsteen updated an issue PuppetDB / PDB-5282 Empty certname in PuppetDB command data results in NullPointerException during startup Change By: Charlie Sharpsteen Summary: Empty certname in PuppetDB command data results in NullPointerException during startup Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.416719.1632261204000.136030.1632267300144%40Atlassian.JIRA.
Jira (PDB-5282) PuppetDB command data results in NullPointerException during startup
Title: Message Title Charlie Sharpsteen updated an issue PuppetDB / PDB-5282 PuppetDB command data results in NullPointerException during startup Change By: Charlie Sharpsteen Priority: Normal Major Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.416719.1632261204000.136027.163226766%40Atlassian.JIRA.
Jira (PDB-5282) PuppetDB command data results in NullPointerException during startup
Title: Message Title
Charlie Sharpsteen updated an issue
PuppetDB / PDB-5282
PuppetDB command data results in NullPointerException during startup
Change By:
Charlie Sharpsteen
PuppetDB "commands" are operations to update the data associated with puppet nodes. These commands are identified by certname, and odd things can happen if an empty string or other null value is provided as the certname. One consequence is a {{java.lang.NullPointerException}} during startup. This When PE DR is enabled, this exception prevents the PuppetDB service from exiting maintenance mode and responding to read and write requests.h2. Reproduction Case - Install PE 2019.8.8 on a CentOS 7 node and add a DR replica - Deactivate an empty certname: {{puppet node deactivate ''}} - Re-start the {{pe-puppetdb}} serviceh3. OutcomeThe deactivate command results in the following error message being recorded to the PuppetDB log:{noformat}2021-09- 21T22 21T23 : 20 21 : 47 07 . 271Z 566Z ERROR [p.p.threadpool] Reporting unexpected error from thread cmd-proc-thread- 13 2 to stderr and logjava.lang.NullPointerException: null at metrics.meters$mark_BANG_.invokeStatic(meters.clj:76) at metrics.meters$mark_BANG_.invoke(meters.clj:72) at metrics.meters$mark_BANG_.invokeStatic(meters.clj:74) at metrics.meters$mark_BANG_.invoke(meters.clj:72) at puppetlabs.puppetdb.command$mark_both_metrics_BANG_.invokeStatic(command.clj:244) at puppetlabs.puppetdb.command$mark_both_metrics_BANG_.invoke(command.clj:240) at puppetlabs.puppetdb.command$process_message$retry__37262.invoke(command.clj:755) at puppetlabs.puppetdb.command$process_message.invokeStatic(command.clj:810) at puppetlabs.puppetdb.command$process_message.invoke(command.clj:742) at puppetlabs.puppetdb.command$message_handler$fn__37274.invoke(command.clj:820) at puppetlabs.puppetdb.threadpool$dochan$fn__36851$fn__36852.invoke(threadpool.clj:116) at puppetlabs.puppetdb.threadpool$gated_execute$fn__36813.invoke(threadpool.clj:69) at clojure.lang.AFn.run(AFn.java:22) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829){noformat}This also leaves behind a command int the PuppetDB processing queue with an empty certname:{noformat}# find /opt/puppetlabs/server/data/puppetdb/stockpile/cmd/q -type f -print -exec cat {} \;/opt/puppetlabs/server/data/puppetdb/stockpile/cmd/q/ 50 20 - 1632262847254 1632266467556 - 115_rm 103_rm -node_3_.json{"certname":"","producer_timestamp":"2021-09- 21T22 21T23 : 20 21 : 47 07 . 139 453 +00:00"}{noformat}Upon restart, the PuppetDB services fails to initialize the command processing pool and never exits maintenance mode:{noformat}2021-09- 21T22 21T23 : 33 22 : 58 20 . 072Z 499Z ERROR [p.p.threadpool] Reporting unexpected error from thread cmd-proc-thread-1 to stderr and logjava.lang.NullPointerException: nullat
Jira (PDB-5282) PuppetDB command data results in NullPointerException during startup
Title: Message Title
Charlie Sharpsteen updated an issue
PuppetDB / PDB-5282
PuppetDB command data results in NullPointerException during startup
Change By:
Charlie Sharpsteen
PuppetDB "commands" are operations to update the data associated with puppet nodes. These commands are identified by certname, and odd things can happen if an empty string or other null value is provided as the certname. One consequence is a {{java.lang.NullPointerException}} during startup. This exception prevents the PuppetDB service from exiting maintenance mode and responding to read and write requests.h2. Reproduction Case - Install PE 2019.8.8 on a CentOS 7 node - Deactivate an empty certname: {{puppet node deactivate ''}} - Re-start the {{pe-puppetdb}} serviceh3 . OutcomeThe deactivate command results in the following error message being recorded to the PuppetDB log:{noformat}2021-09-21T22:20:47.271Z ERROR [p.p.threadpool] Reporting unexpected error from thread cmd-proc-thread-13 to stderr and logjava.lang.NullPointerException: null at metrics.meters$mark_BANG_.invokeStatic(meters.clj:76) at metrics.meters$mark_BANG_.invoke(meters.clj:72) at metrics.meters$mark_BANG_.invokeStatic(meters.clj:74) at metrics.meters$mark_BANG_.invoke(meters.clj:72) at puppetlabs.puppetdb.command$mark_both_metrics_BANG_.invokeStatic(command.clj:244) at puppetlabs.puppetdb.command$mark_both_metrics_BANG_.invoke(command.clj:240) at puppetlabs.puppetdb.command$process_message$retry__37262.invoke(command.clj:755) at puppetlabs.puppetdb.command$process_message.invokeStatic(command.clj:810) at puppetlabs.puppetdb.command$process_message.invoke(command.clj:742) at puppetlabs.puppetdb.command$message_handler$fn__37274.invoke(command.clj:820) at puppetlabs.puppetdb.threadpool$dochan$fn__36851$fn__36852.invoke(threadpool.clj:116) at puppetlabs.puppetdb.threadpool$gated_execute$fn__36813.invoke(threadpool.clj:69) at clojure.lang.AFn.run(AFn.java:22) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829){noformat}This also leaves behind a command int the PuppetDB processing queue with an empty certname:{noformat}# find /opt/puppetlabs/server/data/puppetdb/stockpile/cmd/q -type f -print -exec cat {} \;/opt/puppetlabs/server/data/puppetdb/stockpile/cmd/q/50-1632262847254-115_rm-node_3_.json{"certname":"","producer_timestamp":"2021-09-21T22:20:47.139+00:00"}{noformat}Upon restart, the PuppetDB services fails to initialize the command processing pool and never exits maintenance mode:{noformat}2021-09-21T22:33:58.072Z ERROR [p.p.threadpool] Reporting unexpected error from thread cmd-proc-thread-1 to stderr and logjava.lang.NullPointerException: nullat metrics.meters$mark_BANG_.invokeStatic(meters.clj:76)at metrics.meters$mark_BANG_.invoke(meters.clj:72)at metrics.meters$mark_BANG_.invokeStatic(meters.clj:74)at
Jira (PDB-5282) PuppetDB command data results in NullPointerException during startup
Title: Message Title
Charlie Sharpsteen updated an issue
PuppetDB / PDB-5282
PuppetDB command data results in NullPointerException during startup
Change By:
Charlie Sharpsteen
Under certain unknown circumstances, data stored in the PuppetDB command queue "commands" are operations to update the data associated with puppet nodes. These commands are identified by certname, and odd things can cause happen if an empty string or other null value is provided as the certname. One consequence is a {{java.lang.NullPointerException}} during startup. This exception prevents the PuppetDB service from exiting maintenance mode and responding to read and write requests. h2. Reproduction Case - Install PE 2019.8.8 on a CentOS 7 node - Deactivate an empty certname: {{puppet node deactivate ''}} - Re-start the {{pe-puppetdb}} serviceh3 Outcome The most relevant errors printed deactivate command results in the following error message being recorded to the logs are PuppetDB log :{noformat}2021-09- 21T17 21T22 : 43 20 :47. 616Z INFO [c.z.h.HikariDataSource] PDBWritePool - Start completed.2021-09-21T17:43:47.623Z 271Z ERROR [p.p. c.services threadpool ] Reporting unexpected error from thread cmd-proc-thread-13 to stderr and logjava.lang.NullPointerException: nullat clojure metrics . core meters $ name mark_BANG_ .invokeStatic( core meters .clj: 1595 76 )at clojure metrics . core meters $ name mark_BANG_ .invoke( core meters .clj: 1589 72 )at clojure.core$mapv$fn__8445.invoke(core.clj:6912)at clojure.lang.PersistentVector.reduce(PersistentVector.java:343)at clojure.core$reduce.invokeStatic(core.clj:6827)at clojure.core$mapv.invokeStatic(core.clj:6903)at clojure.core$mapv.invoke(core.clj:6903)at puppetlabs.puppetdb. metrics. core meters $ keyword__GT_metric_name mark_BANG_ .invokeStatic( core meters .clj: 26 74 )at puppetlabs.puppetdb. metrics. core meters $ keyword__GT_metric_name mark_BANG_ .invoke( core meters .clj: 20 72 )at puppetlabs.puppetdb.command$ create_metrics$to_metric_name_fn__36929 mark_both_metrics_BANG_ . invoke(command.clj:169)at puppetlabs.puppetdb.command$create_metrics. invokeStatic(command.clj: 172 244 )at puppetlabs.puppetdb.command$ create_metrics mark_both_metrics_BANG_ .invoke(command.clj: 168 240 )at puppetlabs.puppetdb.command$ create_metrics_for_command_BANG_ process_message $ fn__36935 retry__37262 .invoke(command.clj: 230 755 )at clojure.lang.Atom.swap(Atom.java:37)at clojure.core$swap_BANG_.invokeStatic(core.clj:2352)at clojure.core$swap_BANG_.invoke(core.clj:2345)at puppetlabs.puppetdb.command$ create_metrics_for_command_BANG_ process_message .invokeStatic(command.clj: 222 810 )at puppetlabs.puppetdb.command$ create_metrics_for_command_BANG_ process_message .invoke(command.clj: 215 742 )at puppetlabs.puppetdb.command$ inc_cmd_depth.invokeStatic(command.clj:237)at puppetlabs.puppetdb.command message_handler $ inc_cmd_depth fn__37274 .invoke(command.clj: 233 820 )at
Jira (PDB-5282) Using an empty string as a command certname results in a NullPointerException during startup
Title: Message Title Charlie Sharpsteen updated an issue PuppetDB / PDB-5282 Using an empty string as a command certname results in a NullPointerException during startup Change By: Charlie Sharpsteen Summary: PuppetDB Using an empty string as a command data certname results in a NullPointerException during startup Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.416719.1632261204000.135883.1632263220052%40Atlassian.JIRA.
Jira (PDB-5282) PuppetDB command data results in NullPointerException during startup
Title: Message Title Charlie Sharpsteen created an issue PuppetDB / PDB-5282 PuppetDB command data results in NullPointerException during startup Issue Type: Bug Affects Versions: PDB 6.17.0 Assignee: Unassigned Components: PuppetDB Created: 2021/09/21 2:53 PM Priority: Normal Reporter: Charlie Sharpsteen Under certain unknown circumstances, data stored in the PuppetDB command queue can cause a java.lang.NullPointerException during startup. This exception prevents the PuppetDB service from exiting maintenance mode and responding to read and write requests. The most relevant errors printed to the logs are: 2021-09-21T17:43:47.616Z INFO [c.z.h.HikariDataSource] PDBWritePool - Start completed. 2021-09-21T17:43:47.623Z ERROR [p.p.c.services] Reporting unexpected error to stderr and log java.lang.NullPointerException: null
Jira (PUP-11163) Prevent thundering herd via deterministic run scheduling
Title: Message Title Charlie Sharpsteen assigned an issue to Unassigned Puppet / PUP-11163 Prevent thundering herd via deterministic run scheduling Change By: Charlie Sharpsteen Assignee: Beth Glenfield Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.406175.1625677218000.133800.1632146520033%40Atlassian.JIRA.
Jira (PUP-9208) Requesting new feature for notify messages
Title: Message Title Charlie Sharpsteen commented on PUP-9208 Re: Requesting new feature for notify messages The notify resource basically does two things: Logs a message at a selectable level Generates a refresh event Enhancing notify with something like event_type => failure in addition to event_type => refresh doesn’t seem like much of an overload. I know there are also folks out there that would also appreciate event_type => none as they just want the log message and not the event. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.278957.1538656473000.83703.1626468120230%40Atlassian.JIRA.
Jira (PUP-11161) Support Script shoudl collect logs from puppet_metrics_collector and pe_database timers
Title: Message Title Charlie Sharpsteen created an issue Puppet / PUP-11161 Support Script shoudl collect logs from puppet_metrics_collector and pe_database timers Issue Type: Improvement Assignee: Unassigned Components: Support Script Created: 2021/07/06 8:14 AM Priority: Major Reporter: Charlie Sharpsteen The puppet_metrics_collector and pe_databases modules have been transitioned from using cron to SystemD timers to run scheduled data collection and maintenance tasks. This means that the output of these activities are recorded to JournalD. The support script should collect logs from JournalD for these new timers. Add Comment
Jira (PDB-5135) PuppetDB should warn about resource titles that exceed Postgres index sizes
Title: Message Title Charlie Sharpsteen commented on PDB-5135 Re: PuppetDB should warn about resource titles that exceed Postgres index sizes The PuppetDB terminii that run inside of Puppet Server might be a good spot for this check as they already iterate over catalog resources and report resource events when prepping the data for sybmission to PuppetDB. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.399989.162152585.37542.1621525980249%40Atlassian.JIRA.
Jira (PDB-5135) PuppetDB should warn about resource titles that exceed Postgres index sizes
Title: Message Title Charlie Sharpsteen updated an issue PuppetDB / PDB-5135 PuppetDB should warn about resource titles that exceed Postgres index sizes Change By: Charlie Sharpsteen Team: PuppetDB Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.399989.162152585.37543.1621525980256%40Atlassian.JIRA.
Jira (PDB-5135) PuppetDB should warn about resource titles that exceed Postgres index sizes
Title: Message Title Charlie Sharpsteen created an issue PuppetDB / PDB-5135 PuppetDB should warn about resource titles that exceed Postgres index sizes Issue Type: Improvement Assignee: Unassigned Created: 2021/05/20 8:50 AM Priority: Normal Reporter: Charlie Sharpsteen When PuppetDB inserts data into Postgres, the constraints of the database can cause errors to be raised. A typical example is that Postgres disallows the use of the null byte, "\0", in strings while UTF-8 generally tolerates it. Another constraint comes into play when large data values are inserted into columns that have database indexes: Any data type that can be sorted into a well-defined linear order can be indexed by a btree index. The only limitation is that an index entry cannot exceed approximately one-third of a page (after TOAST compression, if applicable). https://www.postgresql.org/docs/11/btree-intro.html This constraint is typically encountered with resource title values in catalogs or reports and results in an error similar to the following being raised from the storage attempt: 2021-05-11T23:59:47.225Z ERROR [p.p.command] [14,654,263] [store report] Retrying after attempt 0 for node.hostname.example, due to: org.postgresql.util.PSQLException: ERROR: index row size 2720 exceeds maximum 2712 for index "resource_events_resource_timestamp_20210511z" This error is somewhat useful in that it indicates which node tripped the condition. But the
Jira (FACT-3042) Facter should retrieve EC2 metadata using IMDSv2 without requring user configuration
Title: Message Title Charlie Sharpsteen commented on FACT-3042 Re: Facter should retrieve EC2 metadata using IMDSv2 without requring user configuration The AWS SDKs approach this situation by always using IMDSv2 and falling back to IMDSv1: The AWS SDKs use IMDSv2 calls by default. If the IMDSv2 call receives no response, the SDK retries the call and, if still unsuccessful, uses IMDSv1. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html#imds-considerations This is also the approach Ohai takes when gathering ec2_metadata by always including the X-aws-ec2-metadata-token header, even if empty: https://github.com/chef/ohai/blob/v17.1.0/lib/ohai/mixin/ec2_metadata.rb#L121 Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.399711.1621283832000.34427.1621284180023%40Atlassian.JIRA.
Jira (FACT-3042) Facter should retrieve EC2 metadata using IMDSv2 without requring user configuration
Title: Message Title Charlie Sharpsteen updated an issue Facter / FACT-3042 Facter should retrieve EC2 metadata using IMDSv2 without requring user configuration Change By: Charlie Sharpsteen Affects Version/s: FACT 4.0.47 Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.399711.1621283832000.34424.1621283880121%40Atlassian.JIRA.
Jira (FACT-3042) Facter should retrieve EC2 metadata using IMDSv2 without requring user configuration
Title: Message Title Charlie Sharpsteen created an issue Facter / FACT-3042 Facter should retrieve EC2 metadata using IMDSv2 without requring user configuration Issue Type: Improvement Assignee: Unassigned Created: 2021/05/17 1:37 PM Priority: Normal Reporter: Charlie Sharpsteen FACT-2306 introduced support for v2 of the EC2 Instance Meta Data Service. However, this support has to be explicitly enabled by setting the AWS_IMDSv2 environment variable to true. The environment variable requirement creates two points of friction: Using an environment variable instead of an entry in the Facter configuration makes it easy to get differing behavior depending on execution context. The environment that the puppet service receives is configured with a different set of files from that of a user shell which leads to inconsistent behavior. Requiring an environment variable makes AWS instances with HttpTokens=required special in that they require post-installation configuration that existing installation methods, like the puppet_agent module or PE install scripts, do not automate. If possible, Facter should use IMDSv2 automatically when available. Otherwise, Facter should allow IMDSv2 to be controlled by a configuration setting.
Jira (PUP-9563) Using max_queued_requests, agents return to originally scheduled run times
Title: Message Title Charlie Sharpsteen assigned an issue to Unassigned Puppet / PUP-9563 Using max_queued_requests, agents return to originally scheduled run times Change By: Charlie Sharpsteen Assignee: Charlie Sharpsteen Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.299686.1552405921000.178927.1617220140035%40Atlassian.JIRA.
Jira (FACT-2953) os codename should use parent os codename
Title: Message Title Charlie Sharpsteen commented on FACT-2953 Re: os codename should use parent os codename Using VERSION_CODENAME to populate os.distro.codename if it is present in the os-release file seems reasonable to me as it is specified in the documentation for os-release: https://man7.org/linux/man-pages/man5/os-release.5.html Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.389690.1614739764000.157496.1614877380128%40Atlassian.JIRA.
Jira (PUP-10946) Recursive file resources generate dangerous numbers of resource events
Title: Message Title Charlie Sharpsteen moved an issue Puppet / PUP-10946 Recursive file resources generate dangerous numbers of resource events Change By: Charlie Sharpsteen Key: SUP PUP - 2255 10946 Method Found: Customer Feedback Team: Night's Watch Workflow: Support Scrum Team Workflow Issue Type: Task Bug Project: Support Team Puppet Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10946) Recursive file resources generate dangerous numbers of resource events
Title: Message Title Charlie Sharpsteen updated an issue Puppet / PUP-10946 Recursive file resources generate dangerous numbers of resource events Change By: Charlie Sharpsteen Component/s: Types and Providers Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.389668.1614728039000.155624.1614728280046%40Atlassian.JIRA.
Jira (PUP-10946) Recursive file resources generate dangerous numbers of resource events
Title: Message Title Charlie Sharpsteen updated an issue Puppet / PUP-10946 Recursive file resources generate dangerous numbers of resource events Change By: Charlie Sharpsteen Priority: Normal Major Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.389668.1614728039000.155621.1614728220151%40Atlassian.JIRA.
Jira (PDB-5052) puppetlabs-puppetdb module defaults to installing the unsupported combination of Postgres 9.6 and PuppetDB 7
Title: Message Title Charlie Sharpsteen updated an issue PuppetDB / PDB-5052 puppetlabs-puppetdb module defaults to installing the unsupported combination of Postgres 9.6 and PuppetDB 7 Change By: Charlie Sharpsteen Summary: puppetlabs-puppetdb module defaults to installing the unsupported combination of Postgres 9.6 alongside and PuppetDB 7 Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.389161.1614367275000.153250.1614367380029%40Atlassian.JIRA.
Jira (PDB-5052) puppetlabs-puppetdb module defaults to installing Postgres 9.6 alongside PuppetDB 7
Title: Message Title Charlie Sharpsteen created an issue PuppetDB / PDB-5052 puppetlabs-puppetdb module defaults to installing Postgres 9.6 alongside PuppetDB 7 Issue Type: Bug Affects Versions: PDB module-7.7.1 Assignee: Unassigned Components: Module Created: 2021/02/26 11:21 AM Priority: Normal Reporter: Charlie Sharpsteen PuppetDB 7.0 dropped support for PostgresSQL versions older than 11.0: Running PuppetDB with PostgreSQL 9.6 or 10 is no longer supported. Use PostgreSQL 11 or greater instead. https://puppet.com/docs/puppetdb/latest/release_notes.html#upgrading However, version 7.7.1 of the puppetlabs-puppetdb module still defaults to installing PostgreSQL 9.6: https://github.com/puppetlabs/puppetlabs-puppetdb/blob/7.7.1/manifests/params.pp#L27 Add Comment
Jira (FACT-2934) Facter::Core::Execution does not set status variables in Facter 4
Title: Message Title
Charlie Sharpsteen commented on FACT-2934
Re: Facter::Core::Execution does not set status variables in Facter 4
I tried out PE 2021.0.0-rc5-67-gbfc68f0 and the new behavior looks good
# /opt/puppetlabs/puppet/bin/ruby -rfacter -e 'Facter::Core::Execution.execute("false") and puts($?.exitstatus)'
1
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.385912.1612301794000.135003.1612566180025%40Atlassian.JIRA.
Jira (FACT-2939) Restore facter --puppet functionality to Facter 4
Title: Message Title
Charlie Sharpsteen updated an issue
Facter / FACT-2939
Restore facter --puppet functionality to Facter 4
Change By:
Charlie Sharpsteen
Historically, the {{--puppet}} and {{-p}} flags were offered by the Facter CLI to enable loading and reporting custom facts that had been downloaded from a Puppet Server by the Puppet Agent. But, the output of {{facter --puppet}} does not include values added by the {{puppet agent}} to facts submitted with catalog requests and can produce incorrect output when fact resolution is sensitive to the Puppet Environment as a compiler scope is not initialized. These issues led to the {{--puppet}} flag being deprecated in favor of the {{puppet facts show}} CLI in Puppet 7 and Facter 4.However, the {{--puppet}} flag has a very long history in Facter, having been added in 2008. This history has created a large diaspora of {{facter --puppet}} usage in scripts that are not sensitive to the issues fixed by {{puppet facts show}} because they are invoked on agent systems that don't host multiple environments or request fact values that are created by the context of a {{puppet agent}} run.In order to smooth upgrades to Puppet 7 by avoiding a search-and-replace operation to locate existing uses of {{facter --puppet}}, this ticket is a request to restore the functionality of the flag in Facter 4.
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (FACT-2939) Restore facter --puppet functionality to Facter 4
Title: Message Title Charlie Sharpsteen created an issue Facter / FACT-2939 Restore facter --puppet functionality to Facter 4 Issue Type: Improvement Affects Versions: FACT 4.0.50 Assignee: Unassigned Created: 2021/02/04 3:21 PM Priority: Major Reporter: Charlie Sharpsteen Historically, the -puppet and -p flags were offered by the Facter CLI to enable loading and reporting custom facts that had been downloaded from a Puppet Server by the Puppet Agent. But, the output of facter --puppet does not include values added by the puppet agent to facts submitted with catalog requests and can produce incorrect output when fact resolution is sensitive to the Puppet Environment as a compiler scope is not initialized. These issues led to the -puppet flag being deprecated in favor of the puppet facts show CLI in Puppet 7 and Facter 4. However, the --puppet flag has a very long history in Facter, having been added in 2008. This history has created a large diaspora of facter --puppet usage in scripts that are not sensitive to the issues fixed by puppet facts show because they are invoked on agent systems that don't host multiple environments or request fact values that are by the context of a puppet agent run. In order to smooth upgrades to Puppet 7 by avoiding a search-and-replace operation to locate existing uses of facter --puppet, this ticket is a request to restore the functionality of the flag in Facter 4.
Jira (FACT-2934) Facter::Core::Execution does not set status variables in Facter 4
Title: Message Title
Charlie Sharpsteen updated an issue
Facter / FACT-2934
Facter::Core::Execution does not set status variables in Facter 4
Change By:
Charlie Sharpsteen
The {{exec}} and {{execute}} methods of the {{Facter::Core::Execution}} module are commonly used to execute external processes in custom facts. In Facter 4, these methods no longer set the global Ruby variables {{$CHILD_STATUS}} or {{$?}}.This is a regression of FACT-1284 which was its self a regression of behavior present in Facter 2.x and 1.x.h2. Reproduction Case - Install {{puppet-agent}} 7 on CentOS 7:{code:bash}yum install -y http://yum.puppetlabs.com/puppet7-release-el-7.noarch.rpmyum install -y puppet-agentsource /etc/profile.d/puppet-agent.sh{code} - Create a directory containing a custom fact that uses the {{$?}} variable:{code:bash}mkdir exit_code_testcat <<'EOF' > exit_code_test/exit_code_test.rbFacter.add("exit_code_test") do setcode doFacter::Util::Resolution.exec('/usr/bin/false')"/usr/bin/false exited with code: %{ code status }" % { code status : $?.exitstatus} endendEOF{code} - Run Facter:{code:bash}env FACTERLIB=$PWD/exit_code_test facter exit_code_test{code}h3. OutcomeThe fact fails to resolve, logging an error from a `nil` reference:{noformat}# facter --version4.0.49# env FACTERLIB=$PWD/exit_code_test facter exit_code_test[2021-02-02 21:33:19.961928 ] ERROR Facter - Error while resolving custom fact fact='exit_code_test', resolution='': undefined method `exitstatus' for nil:NilClass{noformat}h3. Expected OutcomeThe exit status resolves to 1 as it does in Facter 3:{noformat}# facter --version3.14.14 (commit e36657bea27254f003c8fc71d8ef57454db643e2)# env FACTERLIB=$PWD/exit_code_test facter exit_code_test/usr/bin/false exited with code: 1{noformat}And in Facter 2:{noformat}# facter --version2.5.7# env FACTERLIB=$PWD/exit_code_test facter exit_code_test/usr/bin/false exited with code: 1{noformat}
Add Comment
Jira (FACT-2934) Facter::Core::Execution does not set status variables in Facter 4
Title: Message Title Charlie Sharpsteen commented on FACT-2934 Re: Facter::Core::Execution does not set status variables in Facter 4 I think this is occurring because Facter 4 implements Facter::Core::Execution using Open3.popen3: https://github.com/puppetlabs/facter/blob/4.0.49/lib/facter/custom_facts/core/execution/base.rb#L73 However, Open3 calls Process.detach which spawns a thread to reap the child process. This consumes the exit status of the child without setting the global status variables: https://github.com/ruby/ruby/blob/v2_7_2/lib/open3.rb#L214 Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.385912.1612301794000.131288.1612302060024%40Atlassian.JIRA.
Jira (FACT-2934) Facter::Core::Execution does not set status variables in Facter 4
Title: Message Title Charlie Sharpsteen created an issue Facter / FACT-2934 Facter::Core::Execution does not set status variables in Facter 4 Issue Type: Bug Affects Versions: FACT 4.0.49 Assignee: Unassigned Created: 2021/02/02 1:36 PM Priority: Critical Reporter: Charlie Sharpsteen The exec and execute methods of the Facter::Core::Execution module are commonly used to execute external processes in custom facts. In Facter 4, these methods no longer set the global Ruby variables $CHILD_STATUS or $?. This is a regression of FACT-1284 which was its self a regression of behavior present in Facter 2.x and 1.x. Reproduction Case Install puppet-agent 7 on CentOS 7: yum install -y http://yum.puppetlabs.com/puppet7-release-el-7.noarch.rpm yum install -y puppet-agent source /etc/profile.d/puppet-agent.sh
Jira (PUP-10212) SSL negotiation fails with "tls_process_ske_dhe:dh key too small"
Title: Message Title Charlie Sharpsteen commented on PUP-10212 Re: SSL negotiation fails with "tls_process_ske_dhe:dh key too small" Ah, I see the PE version is 2019.2.1. PE-27944 bumped the Diffie-Hellman key size to 2048, released in PE 2019.4.0. So, it seems this issue should already be fixed in PE. Open Source may be a different question as PE implemented the fix by adding -Djdk.tls.ephemeralDHKeySize=2048 to the JAVA_ARGS managed by PE. But, maybe there is a default value used by the JVM that should be addressed by platform Java providers? Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.336537.1574710008000.126993.1611794160034%40Atlassian.JIRA.
Jira (PUP-9176) puppet module install should list unsatisfiable dependencies if installation fails
Title: Message Title Charlie Sharpsteen commented on PUP-9176 Re: puppet module install should list unsatisfiable dependencies if installation fails This issue still affects current Puppet releases. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.51451.1410900284000.82191.1605724380124%40Atlassian.JIRA.
Jira (PUP-9176) puppet module install should list unsatisfiable dependencies if installation fails
Title: Message Title Charlie Sharpsteen updated an issue Puppet / PUP-9176 puppet module install should list unsatisfiable dependencies if installation fails Change By: Charlie Sharpsteen Affects Version/s: PUP 5.5.6 Affects Version/s: PUP 4.10.12 Affects Version/s: PUP 6.0.0 Affects Version/s: PUP 4.10.13 Affects Version/s: PUP 5.5.22 Affects Version/s: PUP 6.19.1 Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PDB-4628) Fields in group_by queries aren't properly quoted/escaped
Title: Message Title Charlie Sharpsteen updated an issue PuppetDB / PDB-4628 Fields in group_by queries aren't properly quoted/escaped Change By: Charlie Sharpsteen CS Priority: Needs Priority Team: PuppetDB Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.342668.1579529055000.40831.1600809180247%40Atlassian.JIRA.
Jira (PDB-4628) Fields in group_by queries aren't properly quoted/escaped
Title: Message Title Charlie Sharpsteen updated an issue PuppetDB / PDB-4628 Fields in group_by queries aren't properly quoted/escaped Change By: Charlie Sharpsteen Issue Type: Story Bug Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.342668.1579529055000.40832.1600809180291%40Atlassian.JIRA.
Jira (PUP-7582) Make attempt to export or virtualize a class an error
Title: Message Title Charlie Sharpsteen commented on PUP-7582 Re: Make attempt to export or virtualize a class an error I've never seen this done in the wild, but also haven't been specifically looking for things like it. Sounds like there has been a deprecation warning since 4.10, so I'd say go ahead and change the behavior in 7 if this is something we want to clean up. We could always flip it back in 7.0.1 if it turns out to break $really_important_use_case that noone has mentioned in 3 years. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.19.1495458026000.40341.1600787700172%40Atlassian.JIRA.
Jira (PUP-10664) Puppet 6 should log connection error details when a functional puppet master cannot be located
Title: Message Title Charlie Sharpsteen commented on PUP-10664 Re: Puppet 6 should log connection error details when a functional puppet master cannot be located Yes, I think we should log all errors that result in the agent failing over to the next server in the list even if the run is ultimately successful. The error messages have important context that may be needed to restore the first server in the list to a healthy state. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.371698.1599857641000.36494.1600193220093%40Atlassian.JIRA.
Jira (PUP-10664) Puppet 6 should log connection error details when a functional puppet master cannot be located
Title: Message Title Charlie Sharpsteen updated an issue Puppet / PUP-10664 Puppet 6 should log connection error details when a functional puppet master cannot be located Change By: Charlie Sharpsteen Team: Coremunity Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.371698.1599857641000.34825.1599858720029%40Atlassian.JIRA.
Jira (PUP-10664) Puppet 6 should log connection error details when a functional puppet master cannot be located
Title: Message Title
Charlie Sharpsteen updated an issue
Puppet / PUP-10664
Puppet 6 should log connection error details when a functional puppet master cannot be located
Change By:
Charlie Sharpsteen
At the beginning of each run, the Puppet agent performs a health check to locate a functional Puppet Server to make API calls to. If this health check fails, the run fails with the following message:{noformat}Error: Could not run Puppet configuration client: Could not select a functional puppet master from server_list: 'localhost:8140'{noformat}In order to facilitate troubleshooting, the messages logged at error level should include some detail of what happened to the health check.h2. Reproduction Case - Install Puppet 6 on CentOS 7:{code:bash}yum install -y http://yum.puppetlabs.com/puppet6-release-el-6.noarch.rpmyum install -y puppetserver{ coode code } - Configure the agent to check in locally and bootstrap the Puppet Server CA:{code:bash}source /etc/profile.d/puppet-agent.shpuppet config set server $(hostname -f)puppetserver ca setupsystemctl start puppetserver{code} - Provoke a health check failure by running the Puppet agent with the server url set to {{localhoost}}:{code:bash}puppet agent -t --server_list=localhost:8140{code}h3. OutcomeThe error message is very terse and just states that a healthy server could not be found:{noformat}# puppet --version6.18.0# puppet agent -t --server_list=localhost:8140Error: Could not run Puppet configuration client: Could not select a functional puppet master from server_list: 'localhost:8140'{noformat}h3. Expected OutcomeRaising the log level to DEBUG reveals that the health check failed due to a SSL validation error. These details should be logged at ERROR level so that the root cause of connection failures is visible for post-mortem debugging:{noformat}# puppet agent -t --server_list=localhost:8140 --debug...Debug: Unable to connect to server from server_list setting: Server hostname 'localhost' did not match server certificate; expected one of dull-sanatorium.delivery.puppetlabs.net, DNS:puppet, DNS:dull-sanatorium.delivery.puppetlabs.net...Error: Could not run Puppet configuration client: Could not select a functional puppet master from server_list: 'localhost:8140'{noformat}
Add Comment
Jira (PUP-10664) Puppet 6 should log connection error details when a functional puppet master cannot be located
Title: Message Title Charlie Sharpsteen updated an issue Puppet / PUP-10664 Puppet 6 should log connection error details when a functional puppet master cannot be located Change By: Charlie Sharpsteen Priority: Normal Major Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.371698.1599857641000.34815.1599857760088%40Atlassian.JIRA.
Jira (PUP-10664) Puppet 6 should log connection error details when a functional puppet master cannot be located
Title: Message Title Charlie Sharpsteen created an issue Puppet / PUP-10664 Puppet 6 should log connection error details when a functional puppet master cannot be located Issue Type: Improvement Affects Versions: PUP 6.18.0 Assignee: Unassigned Created: 2020/09/11 1:54 PM Priority: Normal Reporter: Charlie Sharpsteen At the beginning of each run, the Puppet agent performs a health check to locate a functional Puppet Server to make API calls to. If this health check fails, the run fails with the following message: Error: Could not run Puppet configuration client: Could not select a functional puppet master from server_list: 'localhost:8140' In order to facilitate troubleshooting, the messages logged at error level should include some detail of what happened to the health check. Reproduction Case Install Puppet 6 on CentOS 7: yum install -y
Jira (PUP-10233) environment_classes API endpoint extremely slow
Title: Message Title Charlie Sharpsteen commented on PUP-10233 Re: environment_classes API endpoint extremely slow I'm a bit confused by: This spawns 32 jruby processes hitting: /puppet/v3/environment_classes" How exactly is that activity showing up? As far as I know, that API endpoint is only used by external services like the PE Console. Unless I'm missing something, having 32 request roll in for it seems like bad behavior in some external process. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.341970.157901085.34750.1599853080085%40Atlassian.JIRA.
Jira (PUP-10659) Data Type casts cause Puppet Server to retain Compiler instances
Title: Message Title Charlie Sharpsteen commented on PUP-10659 Re: Data Type casts cause Puppet Server to retain Compiler instances Initializing the constructor functions with the current compilers scope seems to echo PUP-6582. This commit in Puppet changed most function initialization to use nil as the closure scope: https://github.com/puppetlabs/puppet/commit/915d934ad06 Unless new() is special in some way, it seems like the same rationale would apply. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.371191.1599234718000.31029.1599246960044%40Atlassian.JIRA.
Jira (PUP-10657) Resource collector overrides cause Puppet Server to retain Compiler instances
Title: Message Title
Charlie Sharpsteen updated an issue
Puppet / PUP-10657
Resource collector overrides cause Puppet Server to retain Compiler instances
Change By:
Charlie Sharpsteen
Use of a resource collector with an override block will cause Puppet Server to retain {{Puppet::Parser::Catlog}} objects in memory after requests finish.See SERVER-2874 for more context and PE reproduction case.h2. Reproduction Case - Install Puppet Server on CentOS 7 along with the Java development tools:{code:bash}yum install -y http://yum.puppetlabs.com/puppet6-release-el-7.noarch.rpmyum install -y puppetserver java-develsource /etc/profile.d/puppet-agent.sh{code} - Install the `pupeptlabs-inifile` module and use it to enable JRuby class reification. This allows Ruby objects, like {{Puppet::Parser::Compiler}}, to be identified easily in the Java heap:{code:bash}puppet module install puppetlabs-inifilepuppet apply <<'EOF'ini_subsetting { 'Enable JRuby reify.classes': ensure=> present, path => '/etc/sysconfig/puppetserver', section => '', key_val_separator => '=', setting => 'JAVA_ARGS', subsetting=> '-Djruby.reify.classes', value => '=true',}EOF{code} - Bootstrap the CA, configure the agent, and start the {{puppetserver}} service:{code:bash}puppetserver ca setuppuppet config set server $(hostname -f)systemctl start puppetserver{code} - Give the service a trivial catalog to compile:{code:bash}cat <<'EOF' > /etc/puppetlabs/code/environments/production/manifests/site.ppnode default { notify { 'test message':message => regsubst( 'Hello, foo world !', 'foo', 'world') } Notify <| title == 'test message' |> {message => 'collector override', }}EOF{code} - Run {{puppet}} a couple of times:{code:bash}puppet agent -tpuppet agent -t{code} - Check the number of {{Puppet::Parser::Compiler}} instances retained in Puppet Server memory:{code:bash}sudo -u puppet jmap -histo:live $(systemctl show -p MainPID puppetserver|cut -d= -f2)|fgrep 'rubyobj.Puppet.Parser.Compiler'{code}h3. OutcomeAfter running the agent twice, the {{puppetserver}} service is retaining two Compiler instances in memory:{noformat}# sudo -u puppet jmap -histo:live $(systemctl show -p MainPID puppetserver|cut -d= -f2)|fgrep 'rubyobj.Puppet.Parser.Compiler'5895: 2 64 rubyobj.Puppet.Parser.Compiler{noformat}h3. Expected OutcomeNo compiler instances should be retained as the compiler is discarded at the end of the request and the {{-histo:live}} flag forces a full garbage collection.
Jira (PUP-10659) Data Type casts cause Puppet Server to retain Compiler instances
Title: Message Title
Charlie Sharpsteen commented on PUP-10659
Re: Data Type casts cause Puppet Server to retain Compiler instances
The following re-factor of the new_function_for method appears to solve the leak:
def new_function_for_type(t, scope)
@new_function_cache ||= {}
if ! @new_function_cache.key?(t)
@new_function_cache[t] = t.new_function.new(nil, loader)
end
@new_function_cache[t]
end
The main functional change is passing nil when creating the constructor function instead of passing scope. It seems like this should be fine as functions will fall back to using the current Compiler's global scope if the value previously populated by scope is referenced: https://github.com/puppetlabs/puppet/blob/6.18.0/lib/puppet/pops/functions/function.rb#L78-L79 Also, having constructor functions created in subsequent compilations be dependent on the scope of the first Compiler ever created seems like it would be bug.
Jira (PUP-10659) Data Type casts cause Puppet Server to retain Compiler instances
Title: Message Title
Charlie Sharpsteen commented on PUP-10659
Re: Data Type casts cause Puppet Server to retain Compiler instances
The cause of this appears to be two behaviors in the following section of code in lib/puppet/functions/new.rb:
def new_function_for_type(t, scope)
@new_function_cache ||= Hash.new() {|hsh, key| hsh[key] = key.new_function.new(scope, loader) }
@new_function_cache[t]
end
https://github.com/puppetlabs/puppet/blob/6.18.0/lib/puppet/functions/new.rb This maintains a cache of constructor functions for each datatype: new String, new Integer, etc. The two issues are:
The cache is a Hash instance with a lambda function that creates constructor functions as they are requested. This lambda closes over the Compiler scope value passed the first time new() is called, which keeps that scope in memory.
The Compiler scope value passed the first time new() is called is further passed into the constructor function when it is created. The function then stores it as a local variable: https://github.com/puppetlabs/puppet/blob/6.18.0/lib/puppet/pops/functions/function.rb#L23
Aside from the memory leak, it seems wrong to be using the scope of the first Compiler that happens to call new() to provide data for subsequent compilations.
Add Comment
Jira (PUP-10659) Data Type casts cause Puppet Server to retain Compiler instances
Title: Message Title Charlie Sharpsteen updated an issue Puppet / PUP-10659 Data Type casts cause Puppet Server to retain Compiler instances Change By: Charlie Sharpsteen Summary: Data Type casts case cause Puppet Server to retain Compiler instances Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.371191.1599234718000.30782.1599235800027%40Atlassian.JIRA.
Jira (PUP-10659) Data Type casts case Puppet Server to retain Compiler instances
Title: Message Title
Charlie Sharpsteen created an issue
Puppet / PUP-10659
Data Type casts case Puppet Server to retain Compiler instances
Issue Type:
Bug
Affects Versions:
PUP 5.5.21, PUP 6.18.0
Assignee:
Unassigned
Components:
Functions
Created:
2020/09/04 8:51 AM
Priority:
Normal
Reporter:
Charlie Sharpsteen
Casting between Puppet Data Types, such as Integer("9"), will cause Puppet Server to retain Puppet::Parser::Catlog objects in memory after requests finish. See SERVER-2874 for more context and PE reproduction case. Reproduction Case
Install Puppet Server on CentOS 7 along with the Java development tools:
yum install -y http://yum.puppetlabs.com/puppet6-release-el-7.noarch.rpm
yum install -y puppetserver java-devel
source /etc/profile.d/puppet-agent.sh
Jira (PUP-10657) Resource collector overrides cause Puppet Server to retain Compiler instances
Title: Message Title Charlie Sharpsteen commented on PUP-10657 Re: Resource collector overrides cause Puppet Server to retain Compiler instances Ideally, we wouldn't override the child_of? method to short-circuit the logic. Something like a force: true option for adding overrides to resources would be a much nicer way of doing this. That said, using instance_eval to re-define the method seems to produce the same effect as meta_def but without leaving a reference to the Proc binding on the eigenclass. So, this may be a quick solution tat requires fewer modifications: overrides[:source].instance_eval do def child_of?(klass) true end end Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10657) Resource collector overrides cause Puppet Server to retain Compiler instances
Title: Message Title
Charlie Sharpsteen updated an issue
Puppet / PUP-10657
Resource collector overrides cause Puppet Server to retain Compiler instances
Change By:
Charlie Sharpsteen
Use of a resource collector with an override block will cause Puppet Server to retain {{Puppet::Parser::Catlog}} objects in memory after requests finish.See SERVER-2874 for more context and PE reproduction case.h2. Reproduction Case - Install Puppet Server on CentOS 7 along with the Java development tools:{code:bash}yum install -y http://yum.puppetlabs.com/puppet6-release-el-7.noarch.rpmyum install -y puppetserver java-develsource /etc/profile.d/puppet-agent.sh{code} - Install the `pupeptlabs-inifile` module and use it to enable JRuby class reification. This allows Ruby objects, like {{Puppet::Parser::Compiler}}, to be identified easily in the Java heap:{code:bash}puppet module install puppetlabs-inifilepuppet apply <<'EOF'ini_subsetting { 'Enable JRuby reify.classes': ensure=> present, path => '/etc/sysconfig/puppetserver', section => '', key_val_separator => '=', setting => 'JAVA_ARGS', subsetting=> '-Djruby.reify.classes', value => '=true',}EOF{code} - Bootstrap the CA, configure the agent, and start the {{puppetserver}} service:{code:bash}puppetserver ca setuppuppet config set server $(hostname -f)systemctl start puppetserver{code} - Give the service a trivial catalog to compile:{code:bash} cat <<'EOF' > /etc/puppetlabs/code/environments/production/manifests/site.pp node default { notify { 'test message':message => regsubst('Hello, foo!', 'foo', 'world') } Notify <| title == 'test message' |> {message => 'collector override', }} EOF {code} - Run {{puppet}} a couple of times:{code:bash}puppet agent -tpuppet agent -t{code} - Check the number of {{Puppet::Parser::Compiler}} instances retained in Puppet Server memory:{code:bash}sudo -u puppet jmap -histo:live $(systemctl show -p MainPID puppetserver|cut -d= -f2)|fgrep 'rubyobj.Puppet.Parser.Compiler'{code}h3. OutcomeAfter running the agent twice, the {{puppetserver}} service is retaining two Compiler instances in memory:{noformat}# sudo -u puppet jmap -histo:live $(systemctl show -p MainPID puppetserver|cut -d= -f2)|fgrep 'rubyobj.Puppet.Parser.Compiler'5895: 2 64 rubyobj.Puppet.Parser.Compiler{noformat}h3. Expected OutcomeNo compiler instances should be retained as the compiler is discarded at the end of the request and the {{-histo:live}} flag forces a full garbage collection.
Jira (PUP-10657) Resource collector overrides cause Puppet Server to retain Compiler instances
Title: Message Title Charlie Sharpsteen commented on PUP-10657 Re: Resource collector overrides cause Puppet Server to retain Compiler instances This leak is caused by the following lines of code in the Resource Collector implementation: overrides[:source].meta_def(:child_of?) do |klass| true end https://github.com/puppetlabs/puppet/blob/6.18.0/lib/puppet/pops/evaluator/collectors/abstract_collector.rb#L48-L50 That loops over resources the collector is operating on and modifies their child_of? methods to always return true. This forces the collector overrides to be merged in later by short-circuiting the logic in Puppet::Parser::Resource that only accepts overrides from a parent scope: https://github.com/puppetlabs/puppet/blob/6.18.0/lib/puppet/parser/resource.rb#L167-L169 https://github.com/puppetlabs/puppet/blob/6.18.0/lib/puppet/parser/resource.rb#L361 However, overriding a method like this results in the creation of a Ruby "eigenclass" to hold the new method definition. The body of the method, which accepts klass and always returns true, is provided by Ruby block. This block is an instance of a Proc, which means that it closes over all variables that happen to be in scope. One of those variables is @scope, which is a reference to the compiler scope. JRuby doesn't always free eigenclass instances when the objects they were created to modify go out of scope: https://github.com/jruby/jruby/issues/4968 So, whenever a Resource Collector is used to override parameters, we end up with unused eigenclasses that hold onto references for one or more compilers. Add Comment
Jira (PUP-10657) Resource collector overrides cause Puppet Server to retain Compiler instances
Title: Message Title Charlie Sharpsteen created an issue Puppet / PUP-10657 Resource collector overrides cause Puppet Server to retain Compiler instances Issue Type: Bug Affects Versions: PUP 5.5.21, PUP 6.18.0 Assignee: Unassigned Created: 2020/09/02 4:15 PM Priority: Normal Reporter: Charlie Sharpsteen Use of a resource collector with an override block will cause Puppet Server to retain Puppet::Parser::Catlog objects in memory after requests finish. See SERVER-2874 for more context and PE reproduction case. Reproduction Case Install Puppet Server on CentOS 7 along with the Java development tools: yum install -y http://yum.puppetlabs.com/puppet6-release-el-7.noarch.rpm yum install -y puppetserver java-devel source /etc/profile.d/puppet-agent.sh
Jira (PUP-10604) Include the puppetserver_gem package provider with core Puppet
Title: Message Title Charlie Sharpsteen updated an issue Puppet / PUP-10604 Include the puppetserver_gem package provider with core Puppet Change By: Charlie Sharpsteen CS Priority: Needs Priority Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.367865.1596151607000.5851.1596151740175%40Atlassian.JIRA.
Jira (PUP-10604) Include the puppetserver_gem package provider with core Puppet
Title: Message Title Charlie Sharpsteen commented on PUP-10604 Re: Include the puppetserver_gem package provider with core Puppet The break introduced by PUP-6488 derails a PE upgrade as PE compilers will not be able to apply catalogs required to complete their upgrades until the issue is diagnosed and fixed. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.367865.1596151607000.5847.1596151680033%40Atlassian.JIRA.
Jira (PUP-10604) Include the puppetserver_gem package provider with core Puppet
Title: Message Title Charlie Sharpsteen created an issue Puppet / PUP-10604 Include the puppetserver_gem package provider with core Puppet Issue Type: Improvement Affects Versions: PUP 5.5.20, PUP 6.17.0 Assignee: Unassigned Components: Types and Providers Created: 2020/07/30 4:26 PM Priority: Normal Reporter: Charlie Sharpsteen The core puppet types and providers include a puppet_gem provider for the package resource that knows how to interact with the Ruby interpreter bundled with the puppet-agent package. The puppetserver service also bundles its own JRuby interpreter and requires the used of the puppetserver gem command to install packages. There is an unsupported module, puppetlabs/puppetserver_gem, that adds a puppetserver_gem provider for package resources that fills an analogous role. However, having this provider de-coupled from the Puppet core means it can be broken by changes in the core in a way that interferes with upgrades. PUP-6488 was one such instance where the parent Gem provider was altered in a way that was incompatible with puppet_gem and puppetserver_gem. Both providers were patched, but the breakage in puppet_gem was automatically resolved by an upgrade while the breakage in puppetserver_gem requires users to discover, understand, and then upgrade the module. To prevent these sorts of issues, puppetserver_gem provider should be bundled along with puppet_gem by puppet-agent.
Jira (PDB-4345) Add name field to resource_events to avoid further duplication errors
Title: Message Title Charlie Sharpsteen updated an issue PuppetDB / PDB-4345 Add name field to resource_events to avoid further duplication errors Change By: Charlie Sharpsteen Fix Version/s: PDB 6.0.4 Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.304800.1555358173000.111992.1595278740025%40Atlassian.JIRA.
Jira (PDB-4345) Add name field to resource_events to avoid further duplication errors
Title: Message Title Charlie Sharpsteen updated an issue PuppetDB / PDB-4345 Add name field to resource_events to avoid further duplication errors Change By: Charlie Sharpsteen Fix Version/s: PDB 5.2.9 Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.304800.1555358173000.111991.1595278680083%40Atlassian.JIRA.
Jira (FACT-1902) Facter should validate that external/custom/executable facts output proper UTF-8
Title: Message Title Charlie Sharpsteen commented on FACT-1902 Re: Facter should validate that external/custom/executable facts output proper UTF-8 This also came up today in community slack where a windows user couldn't get a catalog due some fact not producing UTF-8 data. Without this sort of checking in Facter, it is very difficult to determine which fact is the problem. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.290197.1546471789000.108393.1594827720216%40Atlassian.JIRA.
Jira (PUP-10532) Puppet fetches metadata for files with "ensure => absent"
Title: Message Title Charlie Sharpsteen updated an issue Puppet / PUP-10532 Puppet fetches metadata for files with "ensure => absent" Change By: Charlie Sharpsteen CS Priority: Needs Priority Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.359734.1590173269000.99742.1593622260267%40Atlassian.JIRA.
Jira (PDB-4785) PuppetDB should fail fast if Postgres is not reachable during startup
Title: Message Title Charlie Sharpsteen created an issue PuppetDB / PDB-4785 PuppetDB should fail fast if Postgres is not reachable during startup Issue Type: Improvement Affects Versions: PDB 6.11.1 Assignee: Unassigned Components: PuppetDB Created: 2020/06/18 12:09 PM Priority: Major Reporter: Charlie Sharpsteen The puppetdb and pe-puppetdb services use large startup-timeouts to accommodate long-running database migrations. Currently, these are set to 4 hours: https://github.com/puppetlabs/puppetdb/blob/6.11.1/project.clj#L232 However, if Postgres is not running or there is a network issue preventing a connection (DNS, Firewall, TLS configuration, other very common suspects) the PuppetDB migration pool will loop indefinitely attempting a re-connection that will always fail. This leads to PuppetDB being stuck in startup for 4 hours until it fails. At a high level, such as the Puppet Enterprise installer, there is no clear indication that the install or upgrade process is blocked waiting for PuppetDB, let alone that PuppetDB is blocked because of an issue with connecting to Postgres. New users won't know to check puppetdb.log to discover what is happening. Therefore, PuppetDB should fail fast if a connection to the database cannot be established. The 4 hour timeout should only apply once a database migration is actually underway.
Jira (PUP-5600) Add "none" parameter to catalog_cache_terminus configuration reference
Title: Message Title Charlie Sharpsteen commented on PUP-5600 Re: Add "none" parameter to catalog_cache_terminus configuration reference Josh Cooper PUP-10160 addresses --noop catalog getting unintentionally applied, but doesn't address the need to prevent Sensitive data from being written to disk. It is a bit of an edge case concern, but having the ability to toggle it off can save many hours of meetings and arguments with some auditors. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.109309.1449873923000.64870.1589829660089%40Atlassian.JIRA.
Jira (PUP-10511) Sensitive data type is lost when declaring multiple resources using title arrays
Title: Message Title
Charlie Sharpsteen updated an issue
Puppet / PUP-10511
Sensitive data type is lost when declaring multiple resources using title arrays
Change By:
Charlie Sharpsteen
*Puppet Version:* 6.15.0, 5.5.20*Puppet Server Version:* N/A*OS Name/Version:* N/AWhen multiple resources are declared using an array of titles, the type information for {{Sensitive}} parameters is lost. This results in type validation errors if a resource declares a data type such as {{Sensitive[String]}}Install Puppet 6 on CentOS 7 and create a defined type with a password parameter declared to be {{Sensitive[String]}}:{code:bash} mkdir -p /etc/puppetlabs/code/environments/production/modules/test_mod/manifests cat <<'EOF' > /etc/puppetlabs/code/environments/production/modules/test_mod/manifests/service.ppdefine test_mod::service( Sensitive[String] $password,){ notify{"${title} ${password}": }}EOF{code}Attempt to apply the following manifest:{code:puppet}test_mod::service { ["ServiceA","ServiceB"]: password => Sensitive("password")}{code}*Desired Behavior:*Output matches individual resources declared in a loop:{noformat}# puppet apply <<'EOF'each(["ServiceA","ServiceB"] ) |String $svc_name| { test_mod::service { $svc_name:password => Sensitive("password") }}EOFNotice: Compiled catalog for olde-pacemaker.delivery.puppetlabs.net in environment production in 0.02 secondsNotice: ServiceA Sensitive [value redacted]Notice: /Stage[main]/Main/Test_mod::Service[ServiceA]/Notify[ServiceA Sensitive [value redacted]]/message: defined 'message' as 'ServiceA Sensitive [value redacted]'Notice: ServiceB Sensitive [value redacted]Notice: /Stage[main]/Main/Test_mod::Service[ServiceB]/Notify[ServiceB Sensitive [value redacted]]/message: defined 'message' as 'ServiceB Sensitive [value redacted]'Notice: Applied catalog in 0.01 seconds{noformat}*Actual Behavior:*Compilation fails when defining the second resource as {{password}} has been coerced to a {{String}}:{noformat}# puppet apply <<'EOF'test_mod::service { ["ServiceA","ServiceB"]: password => Sensitive("password")}EOFError: Test_mod::Service[ServiceB]: parameter 'password' expects a Sensitive[String] value, got String on node olde-pacemaker.delivery.puppetlabs.net{noformat}
Add Comment
Jira (PUP-10511) Sensitive data type is lost when declaring multiple resources using title arrays
Title: Message Title
Charlie Sharpsteen updated an issue
Puppet / PUP-10511
Sensitive data type is lost when declaring multiple resources using title arrays
Change By:
Charlie Sharpsteen
*Puppet Version:* 6.15.0, 5.5.20*Puppet Server Version:* N/A*OS Name/Version:* RedHat 7 N/A When multiple resources are declared using an array of titles, the type information for {{Sensitive}} parameters is lost. This results in type validation errors if a resource declares a data type such as {{Sensitive[String]}}Install Puppet 6 on CentOS 7 and create a defined type with a password parameter declared to be {{Sensitive[String]}}:{code:bash}cat <<'EOF' > /etc/puppetlabs/code/environments/production/modules/test_mod/manifests/service.ppdefine test_mod::service( Sensitive[String] $password,){ notify{"${title} ${password}": }}EOF{code}Attempt to apply the following manifest:{code:puppet}test_mod::service { ["ServiceA","ServiceB"]: password => Sensitive("password")}{code}*Desired Behavior:*Output matches individual resources declared in a loop:{noformat}# puppet apply <<'EOF'each(["ServiceA","ServiceB"] ) |String $svc_name| { test_mod::service { $svc_name:password => Sensitive("password") }}EOFNotice: Compiled catalog for olde-pacemaker.delivery.puppetlabs.net in environment production in 0.02 secondsNotice: ServiceA Sensitive [value redacted]Notice: /Stage[main]/Main/Test_mod::Service[ServiceA]/Notify[ServiceA Sensitive [value redacted]]/message: defined 'message' as 'ServiceA Sensitive [value redacted]'Notice: ServiceB Sensitive [value redacted]Notice: /Stage[main]/Main/Test_mod::Service[ServiceB]/Notify[ServiceB Sensitive [value redacted]]/message: defined 'message' as 'ServiceB Sensitive [value redacted]'Notice: Applied catalog in 0.01 seconds{noformat}*Actual Behavior:*Compilation fails when defining the second resource as {{password}} has been coerced to a {{String}}:{noformat}# puppet apply <<'EOF'test_mod::service { ["ServiceA","ServiceB"]: password => Sensitive("password")}EOFError: Test_mod::Service[ServiceB]: parameter 'password' expects a Sensitive[String] value, got String on node olde-pacemaker.delivery.puppetlabs.net{noformat}
Add Comment
Jira (PUP-10511) Sensitive data type is lost when declaring multiple resources using title arrays
Title: Message Title Charlie Sharpsteen created an issue Puppet / PUP-10511 Sensitive data type is lost when declaring multiple resources using title arrays Issue Type: Bug Affects Versions: PUP 6.15.0, PUP 5.5.20 Assignee: Unassigned Components: Language Created: 2020/05/14 12:03 PM Priority: Normal Reporter: Charlie Sharpsteen Puppet Version: 6.15.0, 5.5.20 Puppet Server Version: N/A OS Name/Version: RedHat 7 When multiple resources are declared using an array of titles, the type information for Sensitive parameters is lost. This results in type validation errors if a resource declares a data type such as Sensitive[String] Install Puppet 6 on CentOS 7 and create a defined type with a password parameter declared to be Sensitive[String]: cat <<'EOF' > /etc/puppetlabs/code/environments/production/modules/test_mod/manifests/service.pp define test_mod::service( Sensitive[String] $password,
Jira (PDB-4599) Remove the "HTTP request received while in maintenance mode" message
Title: Message Title
Charlie Sharpsteen updated an issue
PuppetDB / PDB-4599
Remove the "HTTP request received while in maintenance mode" message
Change By:
Charlie Sharpsteen
PuppetDB currently logs the following message at INFO level every time it receives an API request while in maintenance mode:{quote}HTTP request received while in maintenance mode{quote}https://github.com/puppetlabs/puppetdb/blob/6.7.3/src/puppetlabs/puppetdb/pdb_routing.clj#L30PuppetDB can end up in maintenance mode for tens of minutes or hours if a large migration or replication sync is occurring during starting startup . For deployments with a large volume of traffic, the above message repeats extremely often which bloats the logs and drowns out any indication of migration progress or stalls that are keeping the service in maintenance.Additionally, we log a HTTP 503 status to {{puppetdb-access.log}}, so the message is mostly redundant. We should remove this message provided: - We have clear logging for when the service enters maintenance mode that indicates PDB API requests will be refused. - A request to the {{/status/v1/services}} API shows the system is in maintenance mode.
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10137) HTTP Retry after 408 request timeout or 504 gateway timeout
Title: Message Title Charlie Sharpsteen commented on PUP-10137 Re: HTTP Retry after 408 request timeout or 504 gateway timeout I can't think of a Puppet API that currently uses the 408 or 504 status codes. So, this would mostly be fore retrying requests to 3rd party APIs. This would be useful, but I haven't heard any requests for it and it could also be implemented in the logic of a custom function or provider that needed it. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.334641.1573589453000.36194.1586553240040%40Atlassian.JIRA.
Jira (PUP-10417) Custom Ruby functions that define a JSON module can ambiguate its scope and break Puppet
Title: Message Title Charlie Sharpsteen commented on PUP-10417 Re: Custom Ruby functions that define a JSON module can ambiguate its scope and break Puppet I think the problem is the way customer function definitions are passed to eval(): https://github.com/puppetlabs/puppet/blob/6.14.0/lib/puppet/pops/loader/ruby_function_instantiator.rb#L22 The result is that custom Puppet 4 functions end up sharing Puppet::Pops::Loader::RubyFunctionInstantiator as an enclosing scope instead of being completely isolated from each other. This causes constants declared outside the Puppet::Functions.create_function block to "leak" between Puppet 4 functions. So, someone could run into this even if they weren't trying to monkey-patch the JSON library and just created a new constant for which they decided JSON was the most appropriate name. We could probably fix this, but I also wonder how many people have noticed this behavior and assumed it was an intentional feature they could use to share helper code between functions instead of a flaw in function isolation. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.354928.1586391583000.35210.1586463720080%40Atlassian.JIRA.
Jira (PDB-4678) PuppetDB cannot make DB connections when javax.net.ssl.trustStore is used
Title: Message Title Charlie Sharpsteen updated an issue PuppetDB / PDB-4678 PuppetDB cannot make DB connections when javax.net.ssl.trustStore is used Change By: Charlie Sharpsteen Summary: PuppetDB no longer uses cannot make DB connections when javax.net.ssl.trustStore to validate DB connections is used Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.351066.158509873.20267.1585111860034%40Atlassian.JIRA.
Jira (PDB-4678) PuppetDB no longer uses javax.net.ssl.trustStore to validate DB connections
Title: Message Title Charlie Sharpsteen updated an issue PuppetDB / PDB-4678 PuppetDB no longer uses javax.net.ssl.trustStore to validate DB connections Change By: Charlie Sharpsteen Affects Version/s: PDB 6.9.1 Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.351066.158509873.20235.1585098900042%40Atlassian.JIRA.
Jira (PDB-4678) PuppetDB no longer uses javax.net.ssl.trustStore to validate DB connections
Title: Message Title Charlie Sharpsteen created an issue PuppetDB / PDB-4678 PuppetDB no longer uses javax.net.ssl.trustStore to validate DB connections Issue Type: Bug Affects Versions: PDB 6.8.0 Assignee: Unassigned Created: 2020/03/24 6:12 PM Priority: Major Reporter: Charlie Sharpsteen Prior to PuppetDB 6.8.0, PuppetDB could use the javax.net.ssl.trustStore JVM property to configure which CA certificates to use when validating database connections that use SSL. This is the first configuration method recommended by PuppetDB documentation: https://puppet.com/docs/puppetdb/latest/postgres_ssl.html#using-puppet-certificates-with-the-java-keystore This works in PuppetDB 6.7.3. After upgrading to 6.8.0, it fails silently and leaves the service in an unresponsive state. Reproduction Case Install Puppet Server 6.x on a CentOS 7 VM: yum install -y http://yum.puppetlabs.com/puppet6-release-el-7.noarch.rpm yum install -y puppetserver
Jira (PDB-4599) Remove the "HTTP request received while in maintenance mode" message
Title: Message Title
Charlie Sharpsteen commented on PDB-4599
Re: Remove the "HTTP request received while in maintenance mode" message
Looks like we do have a maintenance_mode? flag in the /status output that indicates PuppetDB is in maintenance mode:
# curl -s http://localhost:8080/status/v1/services/puppetdb-status |python -m json.tool
{
"active_alerts": [],
"detail_level": "info",
"service_name": "puppetdb-status",
"service_status_version": 1,
"service_version": "6.9.1",
"state": "starting",
"status": {
"maintenance_mode?": true,
"queue_depth": 0,
"read_db_up?": false,
"write_db_up?": false
Jira (PDB-4599) Remove the "HTTP request received while in maintenance mode" message
Title: Message Title Charlie Sharpsteen commented on PDB-4599 Re: Remove the "HTTP request received while in maintenance mode" message Another report of this from Community Slack today. User was trying to determine why PuppetDB had not come up in 15 minutes after an upgrade and the only apparant messages in puppetdb.log were "HTTP request received while in maintenance mode" Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.338645.1575914026000.16945.1584661920026%40Atlassian.JIRA.
Jira (PUP-10292) external trusted data is executed for file_content requests
Title: Message Title Charlie Sharpsteen commented on PUP-10292 Re: external trusted data is executed for file_content requests As an aside, the execution of the external command desperately needs to be wrapped in a profiler. So we know when it starts adding seconds of latency to each request Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.346028.1581515567000.1694.1583191080518%40Atlassian.JIRA.
Jira (PDB-4642) Puppet 2019.3 upgrade failure from 2019.2.2
Title: Message Title
Charlie Sharpsteen commented on PDB-4642
Re: Puppet 2019.3 upgrade failure from 2019.2.2
This issue appears to be caused by PuppetDB running migrations in a non-UTC timezone. One workaround that doesn't require truncating the resource events table is to temporarily run PuppetDB with the timezone set to UTC:
On RedHat 6: service pe-puppetdb stop systemctl stop pe-puppetdb
/usr/bin/env TZ=utc /opt/puppetlabs/server/bin/puppetdb foreground
Use Ctrl-C to stop PuppetDB after "PDBMigrationsPool - Shutdown completed" is logged
On RedHat 6: service pe-puppetdb start systemctl start pe-puppetdb {bash}
The above steps should work for Open Source PuppetDB 6.8.1 as well, use puppetdb as the service name instead of pe-puppetdb.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PDB-4642) Puppet 2019.3 upgrade failure from 2019.2.2
Title: Message Title Charlie Sharpsteen commented on PDB-4642 Re: Puppet 2019.3 upgrade failure from 2019.2.2 The migration does not create a table for Jan 31st: grep -o '\(CREATE TABLE IF NOT EXISTS [^[:space:]]\+\)' resource_events_migration.log|sort -u CREATE TABLE IF NOT EXISTS resource_events_20200123Z CREATE TABLE IF NOT EXISTS resource_events_20200124Z CREATE TABLE IF NOT EXISTS resource_events_20200130Z CREATE TABLE IF NOT EXISTS resource_events_20200202Z CREATE TABLE IF NOT EXISTS resource_events_20200203Z CREATE TABLE IF NOT EXISTS resource_events_20200204Z CREATE TABLE IF NOT EXISTS resource_events_20200205Z CREATE TABLE IF NOT EXISTS resource_events_20200206Z CREATE TABLE IF NOT EXISTS resource_events_20200207Z CREATE TABLE IF NOT EXISTS resource_events_20200208Z CREATE TABLE IF NOT EXISTS resource_events_20200209Z
Jira (PDB-4642) Puppet 2019.3 upgrade failure from 2019.2.2
Title: Message Title Charlie Sharpsteen updated an issue PuppetDB / PDB-4642 Puppet 2019.3 upgrade failure from 2019.2.2 Change By: Charlie Sharpsteen Attachment: resource_events_migration.log Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.344931.1580780081000.17651.1581030180771%40Atlassian.JIRA.
Jira (PDB-4642) Puppet 2019.3 upgrade failure from 2019.2.2
Title: Message Title Charlie Sharpsteen commented on PDB-4642 Re: Puppet 2019.3 upgrade failure from 2019.2.2 I can re-produce this using the ZIP archive that Paul Reed uploaded: Get a CentOS 8 VM Set the timezone to EST: timedatectl set-timezone 'America/New_York' Install PE 2019.2.2 Stop PuppetDB: systemctl stop pe-puppetdb Drop the resource_events table: sudo -u pe-postgres /opt/puppetlabs/server/bin/psql -d pe-puppetdb -c 'drop table resource_events' Unpack the ZIP archive, copy resource_events.sql somewhere world-readable, like /tmp, and edit it to remove the last statement (otherwise, import fails): ALTER TABLE ONLY public.resource_events ADD CONSTRAINT resource_events_report_id_fkey FOREIGN KEY (report_id) REFERENCES public.reports(id) ON DELETE CASCADE; Import the edited copy of resource_events.sql:
Jira (PUP-10227) Close the http connection prior to sleeping retry-after seconds
Title: Message Title Charlie Sharpsteen commented on PUP-10227 Re: Close the http connection prior to sleeping retry-after seconds Sorry, missed this one in the sea of mail. Yes, this is a great change. Also, closing on the agent side seems like the best behavior going forward as the Connection: header was removed from HTTP/2. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.341492.1578520569000.16820.1581010500167%40Atlassian.JIRA.
