Jira (PUP-2354) agent is confused about cert state
Title: Message Title Tama MA commented on PUP-2354 Re: agent is confused about cert state Matt Moldvan Your workaround will work. Thank you so much! 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 post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-453) Use more readable log format for the console.
Title: Message Title Michael Smith assigned an issue to Unassigned Puppet Task Runner / BOLT-453 Use more readable log format for the console. Change By: Michael Smith Assignee: Michael Smith 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 post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-453) Use more readable log format for the console.
Title: Message Title Michael Smith assigned an issue to Michael Smith Puppet Task Runner / BOLT-453 Use more readable log format for the console. Change By: Michael Smith Assignee: Nick Lewis Michael Smith 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 post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2354) agent is confused about cert state
Title: Message Title Matt Moldvan commented on PUP-2354 Re: agent is confused about cert state Years later and I ran into this today when attempting to assist set up of an auto scaled environment in AWS. Unfortunate that this is still a thing in 2018. At first appending the EC2 instance id to the beginning of the cert name was working, but when attempting to run Puppet from an EC2 user data script, the behavior was unpredictable and I got the dreaded key mismatch error. So I found allow_duplicate_certs, set it to true and thought we'd be good, but then found this bug report still lingering with one or two "can I have an update" every year or two. I ended up having the devs use uuidgen in the certname option to create a temporary cert when new instances are provisioned. I don't foresee a collision there or issues with accessing the EC2 metadata early in the provision process, so that appears to be a workaround for now. Leaving it here for anyone else that runs into this same issue... 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 post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8667) resource 'tidy' should be less chatty
Title: Message Title
Paul Kranenburg created an issue
Puppet / PUP-8667
resource 'tidy' should be less chatty
Issue Type:
Improvement
Affects Versions:
PUP 5.5.0
Assignee:
Unassigned
Created:
2018/04/18 11:59 AM
Priority:
Normal
Reporter:
Paul Kranenburg
When using the 'tidy' resource to cleanup files, this resource will always report that a given file it manages does not, or no longer, exist. The fact that the file to be tidied up is not present is the expected result, and the report about this fact is unnecessarily verbose. This is the style of message that is produced: Info: /Stage[main]/[...]/Tidy[]: File does not exist at each and every puppet agent run. Suggested fix: In file /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/tidy.rb, at line 337: change info _("File does not exist") to debug _("File does not exist")
Add Comment
Jira (PUP-8645) Prepare release announcement (Puppet Platform 5.5.1)
Title: Message Title Kenn Hussey commented on PUP-8645 Re: Prepare release announcement (Puppet Platform 5.5.1) Garrett Guillotte can this be resolved now? 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 post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-3910) Create new index on reports (start_time)
Title: Message Title Jon-Paul Lindquist updated an issue PuppetDB / PDB-3910 Create new index on reports (start_time) Change By: Jon-Paul Lindquist Summary: Create New Index new index on reports (start_time) 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 post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-3910) Create New Index on reports (start_time)
Title: Message Title Jon-Paul Lindquist commented on PDB-3910 Re: Create New Index on reports (start_time) https://github.com/puppetlabs/puppetdb/pull/2478 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 post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-3910) Create New Index on reports (start_time)
Title: Message Title Jon-Paul Lindquist updated an issue PuppetDB / PDB-3910 Create New Index on reports (start_time) Change By: Jon-Paul Lindquist Comment: https://github.com/puppetlabs/puppetdb/pull/2477 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 post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8664) rpm package provider is too specific
Title: Message Title
Thomas Kishel updated an issue
Puppet / PUP-8664
rpm package provider is too specific
Change By:
Thomas Kishel
*Puppet Version: 5.3.5 (and older)* *Puppet Server Version: N/A* *OS Name/Version: Centos/Redhat*The uninstall method in the rpm package provider is more specific than the package resource it is uninstalling, and uses a cache that can become out of date by the time it executes.*Desired Behavior:*Unconditionally uninstall a package when conditions are not specified.*Actual Behavior:*Example:{code:java} package { 'cronie-anacron': ensure => absent, require => Package['cronie-noanacron'] } package { 'cronie-noanacron': ensure => installed, }{code} {code:java}yum[3546]: Updated: cronie-anacron-1.4.11-19.el7.x86_64 yum[3546]: Updated: cronie-1.4.11-19.el7.x86_64 yum[3546]: Installed: cronie-noanacron-1.4.11-19.el7.x86_64puppet-agent[1371]: (/Stage[main]/Package[cronie-noanacron]/ensure) created puppet-agent[1371]: Execution of '/usr/bin/rpm -e cronie-anacron-1.4.11-17.el7.x86_64' returned 1: error: package cronie-anacron-1.4.11-17.el7.x86_64 is not installed puppet-agent[1371]: (/Stage[main]/Package[cronie-anacron]/ensure) change from '1.4.11-17.el7' to 'absent' failed: Execution of '/usr/bin/rpm -e cronie-anacron-1.4.11-17.el7.x86_64' returned 1: error: package cronie-anacron-1.4.11-17.el7.x86_64 is not installed{code} To reset the test environment after that puppet run, download cronie-1.4.11-14.el7.x86_64.rpm and cronie-anacron-1.4.11-14.el7.x86_64.rpm and run:{code:java}rpm -e cronie cronie-noanacron crontabs ; yum install -y cronie-* ; rpm -qa | grep cron ; puppet agent -t ; rpm -qa | grep cron{code}
Add Comment
Jira (PUP-7163) regression - systemd provider does not honor documented enabled states
Title: Message Title John Gallo commented on PUP-7163 Re: regression - systemd provider does not honor documented enabled states Hello, Any update on fixes/workarounds regarding Puppet Service Resources and Systemctl. All my nodes with a service resource keep on returning a return code of '2' instead of '0', breaking my automation and integrations. 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 post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-3910) Create New Index on reports (start_time)
Title: Message Title
Jon-Paul Lindquist updated an issue
PuppetDB / PDB-3910
Create New Index on reports (start_time)
Change By:
Jon-Paul Lindquist
*Summary*: I would like to propose creating an index on *reports* (_start_time_) to improve query performance. Full details and examples below... We are currently using the latest version of Puppetserver (5.3.0), Puppet (5.5.0), and PuppetDB (5.2.1) in an environment with approximately 600 nodes, which have agent running in noop mode splayed every 60 min, and we are retaining reports on all nodes for 2 years. Over time, this has obviously increased the size of the puppetdb database, specifically the _reports_ table (and _resource_events_). We use [Puppetboard |[http://example.comhttps://github.com/voxpupuli/puppetboard|https://github.com/voxpupuli/puppetboard]] to access and view the reports and history for all the servers in the environment, and it has recently become apparent that there are some long running queries against the database where there is some room for improvement (_examples below_).Puppetboard's index page loads a graph of daily reports (by default for the last 7 days), as seen in the following sample, issuing a query similar to this for each day: {code:java}WITH inactive_nodes AS (SELECT certname FROM certnames WHERE (deactivated IS NOT NULL OR expired IS NOT NULL)) SELECT report_statuses.status AS status, count(*) count FROM reports LEFT JOIN environments ON environments.id = reports.environment_id LEFT JOIN producers ON producers.id = reports.producer_id LEFT JOIN report_statuses ON reports.status_id = report_statuses.id WHERE ((reports.start_time >= '2018-04-16 17:00:00-07') AND (reports.start_time < '2018-04-17 17:00:00-07')) GROUP BY report_statuses.status;{code} With the current size of the database and tables, this query was taking approximately 50-60 seconds to complete on average, ultimately causing performance issues with Postgres, leading to canceled queries on the slave affecting both PuppetDB and Puppetboard, including timeouts while viewing the dashboard.After enabling slow query logging, and analyzing the query, most of the time was spent scanning the reports table only to discard over 2 million rows after the filter was applied:{code:java}puppetdb=# EXPLAIN ANALYZE WITH inactive_nodes AS (SELECT certname FROM certnames WHERE (deactivated IS NOT NULL OR expired IS NOT NULL)) SELECT report_statuses.status AS status, count(*) count FROM reports LEFT JOIN environments ON environments.id = reports.environment_id LEFT JOIN producers ON producers.id = reports.producer_id LEFT JOIN report_statuses ON reports.status_id = report_statuses.id WHERE ((reports.start_time >= '2018-04-16 17:00:00-07') AND (reports.start_time < '2018-04-17 17:00:00-07')) GROUP BY report_statuses.status; QUERY PLAN GroupAggregate (cost=451561.06..451561.08
Jira (PDB-3910) Create New Index on reports (start_time)
Title: Message Title
Jon-Paul Lindquist updated an issue
PuppetDB / PDB-3910
Create New Index on reports (start_time)
Change By:
Jon-Paul Lindquist
*Summary*: I would like to propose creating an index on *reports* (_start_time_) to increase improve query performance. Full details and examples below... We are currently using the latest version of Puppetserver (5.3.0), Puppet (5.5.0), and PuppetDB (5.2.1) in an environment with approximately 600 nodes, which have agent running in noop mode splayed every 60 min, and we are retaining reports on all nodes for 2 years. Over time, this has obviously increased the size of the puppetdb database, specifically the _reports_ table (and _resource_events_). We use [Puppetboard |[http://example.comhttps://github.com/voxpupuli/puppetboard|https://github.com/voxpupuli/puppetboard]] to access and view the reports and history for all the servers in the environment, and it has recently become apparent that there are some long running queries against the database where there is some room for improvement (_examples below_).Puppetboard's index page loads a graph of daily reports (by default for the last 7 days), as seen in the following sample, issuing a query similar to this for each day: {code:java}WITH inactive_nodes AS (SELECT certname FROM certnames WHERE (deactivated IS NOT NULL OR expired IS NOT NULL)) SELECT report_statuses.status AS status, count(*) count FROM reports LEFT JOIN environments ON environments.id = reports.environment_id LEFT JOIN producers ON producers.id = reports.producer_id LEFT JOIN report_statuses ON reports.status_id = report_statuses.id WHERE ((reports.start_time >= '2018-04-16 17:00:00-07') AND (reports.start_time < '2018-04-17 17:00:00-07')) GROUP BY report_statuses.status;{code} With the current size of the database and tables, this query was taking approximately 50-60 seconds to complete on average, ultimately causing performance issues with Postgres, leading to canceled queries on the slave affecting both PuppetDB and Puppetboard, including timeouts while viewing the dashboard.After enabling slow query logging, and analyzing the query, most of the time was spent scanning the reports table only to discard over 2 million rows after the filter was applied:{code:java}puppetdb=# EXPLAIN ANALYZE WITH inactive_nodes AS (SELECT certname FROM certnames WHERE (deactivated IS NOT NULL OR expired IS NOT NULL)) SELECT report_statuses.status AS status, count(*) count FROM reports LEFT JOIN environments ON environments.id = reports.environment_id LEFT JOIN producers ON producers.id = reports.producer_id LEFT JOIN report_statuses ON reports.status_id = report_statuses.id WHERE ((reports.start_time >= '2018-04-16 17:00:00-07') AND (reports.start_time < '2018-04-17 17:00:00-07')) GROUP BY report_statuses.status; QUERY PLAN GroupAggregate
Jira (PDB-3910) Create New Index on reports (start_time)
Title: Message Title
Jon-Paul Lindquist updated an issue
PuppetDB / PDB-3910
Create New Index on reports (start_time)
Change By:
Jon-Paul Lindquist
*Summary*: I would like to propose creating and an index on *reports* (_start_time_) to increase query performance. Full details and examples below... We are currently using the latest version of Puppetserver (5.3.0), Puppet (5.5.0), and PuppetDB (5.2.1) in an environment with approximately 600 nodes, which have agent running in noop mode splayed every 60 min, and we are retaining reports on all nodes for 2 years. Over time, this has obviously increased the size of the puppetdb database, specifically the _reports_ table (and _resource_events_). We use [Puppetboard |[http://example.comhttps://github.com/voxpupuli/puppetboard|https://github.com/voxpupuli/puppetboard]] to access and view the reports and history for all the servers in the environment, and it has recently become apparent that there are some long running queries against the database where there is some room for improvement (_examples below_).Puppetboard's index page loads a graph of daily reports (by default for the last 7 days), as seen in the following sample, issuing a query similar to this for each day: {code:java}WITH inactive_nodes AS (SELECT certname FROM certnames WHERE (deactivated IS NOT NULL OR expired IS NOT NULL)) SELECT report_statuses.status AS status, count(*) count FROM reports LEFT JOIN environments ON environments.id = reports.environment_id LEFT JOIN producers ON producers.id = reports.producer_id LEFT JOIN report_statuses ON reports.status_id = report_statuses.id WHERE ((reports.start_time >= '2018-04-16 17:00:00-07') AND (reports.start_time < '2018-04-17 17:00:00-07')) GROUP BY report_statuses.status;{code} With the current size of the database and tables, this query was taking approximately 50-60 seconds to complete on average, ultimately causing performance issues with Postgres, leading to canceled queries on the slave affecting both PuppetDB and Puppetboard, including timeouts while viewing the dashboard.After enabling slow query logging, and analyzing the query, most of the time was spent scanning the reports table only to discard over 2 million rows after the filter was applied:{code:java}puppetdb=# EXPLAIN ANALYZE WITH inactive_nodes AS (SELECT certname FROM certnames WHERE (deactivated IS NOT NULL OR expired IS NOT NULL)) SELECT report_statuses.status AS status, count(*) count FROM reports LEFT JOIN environments ON environments.id = reports.environment_id LEFT JOIN producers ON producers.id = reports.producer_id LEFT JOIN report_statuses ON reports.status_id = report_statuses.id WHERE ((reports.start_time >= '2018-04-16 17:00:00-07') AND (reports.start_time < '2018-04-17 17:00:00-07')) GROUP BY report_statuses.status; QUERY PLAN GroupAggregate
Jira (PUP-8666) `puppet help lookup` does not indicate that you can use puppet settings
Title: Message Title Johnson Earls created an issue Puppet / PUP-8666 `puppet help lookup` does not indicate that you can use puppet settings Issue Type: Bug Affects Versions: PUP 5.5.0, PUP 5.3.1, PUP 4.10.0 Assignee: Thomas Hallgren Components: CLI, Hiera & Lookup Created: 2018/04/18 7:00 AM Priority: Normal Reporter: Johnson Earls Running puppet help lookup does not indicate that you can use puppet settings as options. For example, puppet help apply includes this text: OPTIONS --- Note that any setting that's valid in the configuration file is also a valid long argument. For example, 'tags' is a
Jira (PUP-8344) Switch to new nightly format for testing with puppetserver latest
Title: Message Title Kenn Hussey updated an issue Puppet / PUP-8344 Switch to new nightly format for testing with puppetserver latest Change By: Kenn Hussey Fix Version/s: PUP 4.10.11 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 post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
