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/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 (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 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 (cost=451561.06..451561.08 ro
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 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 (cost=451561.06..451561.08 ro
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 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 ---
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 index on *reports* (_start_time_) to increase query performance. Full details and explains 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--
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 index on *reports* (_start_time_) to increase query performance. Full details and explains 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:{ noformat 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---
Jira (PDB-3910) Create New Index on reports (start_time)
Title: Message Title Jon-Paul Lindquist created an issue PuppetDB / PDB-3910 Create New Index on reports (start_time) Issue Type: Improvement Assignee: Unassigned Components: PuppetDB Created: 2018/04/17 9:19 PM Environment: CentOS 7 Puppetserver (5.3.0), Puppet (5.5.0), and PuppetDB (5.2.1) Postgres 9.6 (Master + Read Slave) Priority: Normal Reporter: Jon-Paul Lindquist Summary: I would like to propose creating and index on reports (start_time) to increase query performance. Full details and explains 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] 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: WITH inactive_nodes AS (SELECT certname FROM certnames WH
Jira (PUP-8665) Remove any reference/uses of mcollective from acceptance tests
Title: Message Title Enis Inan updated an issue Puppet / PUP-8665 Remove any reference/uses of mcollective from acceptance tests Change By: Enis Inan mcollective is being deprecated for Platform 6. There are still some acceptance tests in the Puppet repo's master branch that reference/use it, and so they need to be cleaned up. 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-8665) Remove any reference/uses of mcollective from acceptance tests
Title: Message Title Enis Inan assigned an issue to Enis Inan Puppet / PUP-8665 Remove any reference/uses of mcollective from acceptance tests Change By: Enis Inan Assignee: Enis Inan 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-8665) Remove any reference/uses of mcollective from acceptance tests
Title: Message Title Enis Inan created an issue Puppet / PUP-8665 Remove any reference/uses of mcollective from acceptance tests Issue Type: Task Assignee: Unassigned Created: 2018/04/17 8:05 PM Fix Versions: PUP 6.0.0 Priority: Normal Reporter: Enis Inan mcollective is being deprecated for Platform 6. There are still some acceptance tests in the Puppet repo's master branch that reference/use it, and so they need to be cleaned up. Add Comment This message was sent by Atlassian JIRA (v7.7.1#7700
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 Method Found: Needs Assessment Customer Feedback 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 Priority: Normal Minor 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 commented on PUP-8664 Re: rpm package provider is too specific Example-Specific Notes: cronie-anacron can't be installed without installing cronie-noanacron first as an alternative. By installing cronie-noanacron, cronie gets updated as a dependency: # rpm -q --requires cronie-noanacron cronie = 1.4.11-19.el7 That in turn updates cronie-anacron: # rpm -q --requires cronie-anacron cronie = 1.4.11-19.el7 So by the time the rpm -e command runs, the cache is no longer valid. Add Comment This message was sent by Atlassian JIRA (v7.7.
Jira (PUP-8664) rpm package provider is too specific
Title: Message Title
Thomas Kishel created an issue
Puppet / PUP-8664
rpm package provider is too specific
Issue Type:
Bug
Affects Versions:
PUP 5.3.5
Assignee:
Unassigned
Components:
Types and Providers
Created:
2018/04/17 4:19 PM
Priority:
Normal
Reporter:
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:
package { 'cronie-anacron':
ensure => absent,
require => Package['cronie-noanacron']
}
Jira (PDB-3909) Switch lucene contains implementation to use WildcardQuery
Title: Message Title Rob Browning created an issue PuppetDB / PDB-3909 Switch lucene contains implementation to use WildcardQuery Issue Type: Bug Assignee: Rob Browning Created: 2018/04/17 4:04 PM Priority: Normal Reporter: Rob Browning Right now it uses RexexpQuery, and may need some improvements to the escaping, but we think a WildcardQuery should behave roughly the same, and the escaping is trivial, so let's swtich to it. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-8552) Make dnf default for fedora, and systemd default for ubuntu/debian
Title: Message Title Kris Bosland updated an issue Puppet / PUP-8552 Make dnf default for fedora, and systemd default for ubuntu/debian Change By: Kris Bosland Acceptance Criteria: Older providers rpm yum and upstart will be defaultfor a specific list of older OS versions, all other OS versions will get the new providers (dnf and systemd) as defaultfor. Currently, we maintain a list of platforms that dnf and systemd are default for. This is unsustainable, as we have to update this list for every new release. What we should be doing is have a blacklist defining which subset of platforms the older provider is default for ( rpm yum and upstart, respectively). This will reduce the long term maintenance costs for these two providers.We already have something like this for upstart, where we have a list of ubuntu platforms that upstart should be the default service provider for. However, the tests fail when we remove the platform restrictions for ubuntu systemd. Older ubuntu versions like 12.04 show that systemd is the default, which is wrong. We need to be careful this does not happen. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-8581) Extract zone type/provider into a module
Title: Message Title Josh Cooper commented on PUP-8581 Re: Extract zone type/provider into a module The module is up at https://github.com/puppetlabs/puppetlabs-zone_core. Validation, unit tests and beaker tests all pass. Just waiting to setup CI pipelines and publish to the forge. 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-2169) Not possible to manage SELinux file contexts via puppet in a sane way
Title: Message Title Branan Riley updated an issue Puppet / PUP-2169 Not possible to manage SELinux file contexts via puppet in a sane way Change By: Branan Riley Labels: linux selinux triaged 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-8582) Add vendor_modules to basemodulepath
Title: Message Title Josh Cooper updated an issue Puppet / PUP-8582 Add vendor_modules to basemodulepath Change By: Josh Cooper Sprint: Platform Core KANBAN 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-3908) Determine/document/handle specific regex syntax
Title: Message Title Rob Browning created an issue PuppetDB / PDB-3908 Determine/document/handle specific regex syntax Issue Type: Bug Assignee: Unassigned Created: 2018/04/17 1:57 PM Priority: Normal Reporter: Rob Browning Figure out what regex syntax/semantics wants to promise to support, document it, and make sure it correctly implements that syntax (which might mean some restricting/quoting of incoming query strings before submission to the existing engine: https://lucene.apache.org/core/7_2_1/core/org/apache/lucene/util/automaton/RegExp.html ). Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-6344) metrics.time.total does not correlate to time reported in log
Title: Message Title Kenn Hussey updated an issue Puppet / PUP-6344 metrics.time.total does not correlate to time reported in log Change By: Kenn Hussey Flagged: Impediment 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-8627) Prepare release announcement (Puppet Platform 5.3.6)
Title: Message Title Garrett Guillotte commented on PUP-8627 Re: Prepare release announcement (Puppet Platform 5.3.6) Puppet agent 5.3.6 is a bug-fix release that includes updates for Puppet 5.3.6 (https://puppet.com/docs/puppet/5.3/release_notes.html), Facter 3.9.6 (https://puppet.com/docs/facter/3.9/release_notes.html), Hiera 3.4.3 (which contains no user-facing changes), and pxp-agent 1.8.3. It also contains updates to curl. For details, see https://puppet.com/docs/puppet/5.3/release_notes_agent.html. PuppetDB 5.1.5 is a minor bug-fix release. For details, see https://puppet.com/docs/puppetdb/5.1/release_notes.html. 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-483) Task to apply a single resource
Title: Message Title
Alex Dreyer updated an issue
Puppet Task Runner / BOLT-483
Task to apply a single resource
Change By:
Alex Dreyer
There is a lot of power in puppet types. We should have a task that allows a user to apply a single resource on a target or targets.{noformat} run_task(bolt::resource, $targets, title=>/etc/puppetlabs/bolt.conf, type='>file', content=>"---\ntransport: pcp", owner=root, mode="777"){noformat} In scope Scope : - applying a single resource Out of scope Scope : - code distribution , types and providers need to be core, pluginsynced or installed manually.- doing anything without the puppet agent package installed.
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@googl
Jira (HI-599) Hiera cannot interpolate non-string values
Title: Message Title Trevor Vaughan commented on HI-599 Re: Hiera cannot interpolate non-string values Henrik Lindberg I think that scope should work the same way as alias. It makes sense. I can see that some people might rely on that but that seems like a bug and should be treated as such. In theory, your Hiera data is getting passed into your classes and everything should be strongly typed at this point (hopefully). 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-483) Task to apply a single resource
Title: Message Title Alex Dreyer created an issue Puppet Task Runner / BOLT-483 Task to apply a single resource Issue Type: New Feature Assignee: Unassigned Created: 2018/04/17 9:42 AM Priority: Normal Reporter: Alex Dreyer There is a lot of power in puppet types. We should have a task that allows a user to apply a single resource on a target or targets. In scope: Out of scope: code distribution Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (BOLT-451) I would like to suppress notice level run_* logging in my plan
Title: Message Title David Kramer updated an issue Puppet Task Runner / BOLT-451 I would like to suppress notice level run_* logging in my plan Change By: David Kramer Sprint: Bolt Ready for Grooming Kanban 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-451) I would like to suppress notice level run_* logging in my plan
Title: Message Title
Alex Dreyer updated an issue
Puppet Task Runner / BOLT-451
I would like to suppress notice level run_* logging in my plan
Change By:
Alex Dreyer
When writing a plan that loops over nodes running a set of tasks on them the default notice level logging can swamp intentional log messages unless they are written at the warn level.run_task, run_command, run_script, upload_file functions should accept a '_quiet' option OR we can expose functions to tell the executor whether to log step messages at notice or info. Possible solutions: Function {noformat} - A CLI flag --quiet to wihtout_default_logging { run_task(...) run_command(...) run_plan(...)}{noformat}Everything run inside the block will log at warn run_* functions with info level - An option to logging instead of notice level logging. If a subplan is called inside the block run_* to disable executor calls will not be logged at notice messages . If a subplan is called outside the block it may call {{without_default_logging}} and suppress logging for some run_* calls inside itself.If {{without_default_logging}} is called within a {{without_default_logging}} block it is essentially a noop.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (BOLT-416) integrate the Hands-On Lab into the existing documentation
Title: Message Title David Kramer assigned an issue to Unassigned Puppet Task Runner / BOLT-416 integrate the Hands-On Lab into the existing documentation Change By: David Kramer Assignee: Kate Lopresti 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-4212) Create a Splay "Start Time" Setting
Title: Message Title Nick Walker commented on PUP-4212 Re: Create a Splay "Start Time" Setting Geoff Nichols I'm fine to close this. I don't think PUP-7452 completely negates the desire to run puppet on an agent at a specific time but I think it reduces the need for this implementation. We can always still run puppet out of cron. 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 (HI-599) Hiera cannot interpolate non-string values
Title: Message Title Henrik Lindberg commented on HI-599 Re: Hiera cannot interpolate non-string values I could argue that scope should work the same way as alias - it is not backwards compatible though to make such a change as some may rely on it interpolating the variable as a string. I am very reluctant to introduce new interpolation functions (especially when they are not actual string interpolations) and I am also very reluctant to introduce any syntax into the data values used in hiera data. What we could do is to solve this with lookup_options - we have a ticket for a real alias expressed in lookup_options. Would not be terribly hard to also support a variable/dig reference (mutually exclusive with use of alias). 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-8660) "puppet apply" should not ignore updated custom facts within the module under test
Title: Message Title Owen Rodabaugh updated an issue Puppet / PUP-8660 "puppet apply" should not ignore updated custom facts within the module under test Change By: Owen Rodabaugh CS Priority: Needs Priority Minor CS Impact: This behavior is very surprising to the user and requires significant effort to track down what is happening and figure out how to work around it. Ideally `puppet apply` would not rely on the cache, or provide some sort of switch to force using the modulepath. CS Severity: 3 - Serious CS Business Value: 2 - $$$ CS Frequency: 2 - 5-25% of Customers Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (HI-599) Hiera cannot interpolate non-string values
Title: Message Title Trevor Vaughan commented on HI-599 Re: Hiera cannot interpolate non-string values Henrik Lindberg Unfortunately, using scope still results in a String instead of a Boolean value. 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 (PDOC-239) In the class list in REFERENCE.md, the class description is cut off
Title: Message Title Nick Miller commented on PDOC-239 Re: In the class list in REFERENCE.md, the class description is cut off Eric Putnam, thanks. One of my team members found that that was documented after I wrote this ticket, it was just a little jarring to see half a word in my summary. That seems like a fine solution, we just don't have ant of our modules using it yet. 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 (PDOC-239) In the class list in REFERENCE.md, the class description is cut off
Title: Message Title Eric Putnam commented on PDOC-239 Re: In the class list in REFERENCE.md, the class description is cut off Nick Miller, this is by design to keep the blurbs in the table of contents short and the table of contents readable. The TOC line prefers the @summary tag and I would encourage you to take advantage of it. In retrospect, perhaps it should display the @summary or nothing. 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 (HI-599) Hiera cannot interpolate non-string values
Title: Message Title
Henrik Lindberg commented on HI-599
Re: Hiera cannot interpolate non-string values
In a custom backend you can do whatever you want. The lookup_key kind does not automatically perform hira interpolation of the returned values. For a data_hash you would return a hash where the variable reference is already resolved using for example the {[dig}} function to drill down into the value.
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 (HI-599) Hiera cannot interpolate non-string values
Title: Message Title
Henrik Lindberg commented on HI-599
Re: Hiera cannot interpolate non-string values
Right, alias does not actually work because that is a lookup in hiera, not a variable reference. The documentation shows that there also is a scope interpolation function (See https://puppet.com/docs/puppet/5.0/hiera_interpolation.html#using-interpolation-functions). Have you tried:
docker::selinux_enabled: "%{scope(facts.selinux.enabled)}"
That seems to be what you are after? Not sure if it retains the data type of the variable though.
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 (HI-599) Hiera cannot interpolate non-string values
Title: Message Title Trevor Vaughan commented on HI-599 Re: Hiera cannot interpolate non-string values Henrik Lindberg Yes, unfortunately, that doesn't work with facts. Since the use of typed facts is now the norm, Hiera should be able to have a way to ensure that the data type of facts is preserved. 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-8634) Chown of ssldir Causing Failures
Title: Message Title Daniel Mcilhagga assigned an issue to Geoff Nichols Puppet / PUP-8634 Chown of ssldir Causing Failures Change By: Daniel Mcilhagga Assignee: Daniel Mcilhagga Geoff Nichols 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-1913) Puppet user resource should respect the forcelocal option
Title: Message Title
Stefan Förster commented on PUP-1913
Re: Puppet user resource should respect the forcelocal option
With forcelocal => true adding a user with expiry => absent will not only trigger usage of the "wrong" commands, but also a usage error on CentOS 6:
Notice: /Stage[main]/Access/Access::Account[testuser]/File[/etc/ssh/authorized_keys.sftp.d/testuser]/ensure: defined content as '{md5}f67ab78e2b49dfcd6a5d4cc9b69749e8'
Debug: /Stage[main]/Access/Access::Account[testuser]/File[/etc/ssh/authorized_keys.sftp.d/testuser]: The container Access::Account[testuser] will propagate my refresh event
Debug: Executing: '/usr/sbin/luseradd -c F-I Fonddurchschau (bayn, production) -g sftp -d /home/testuser -p !! -s /sbin/nologin -u 18048 testuser'
Debug: Executing: '/usr/sbin/usermod -G testuser'
Debug: Executing: '/usr/sbin/lusermod -e testuser'
Error: Could not set expiry on user[testuser]: Execution of '/usr/sbin/lusermod -e testuser' returned 1: Error parsing arguments: unknown option.
Usage: lusermod [-imLU?] [-i|--interactive] [-c|--gecos STRING]
[-d|--directory STRING] [-m|--movedirectory] [-s|--shell STRING]
[-u|--uid NUM] [-g|--gid NUM] [-l|--login STRING]
[-P|--plainpassword STRING] [-p|--password STRING] [-L|--lock]
