Jira (PDB-5450) Slow fact queries after PuppetDB 7.9.0 upgrade when using Postgres 12 with jit enabled
Title: Message Title Elof Ofel commented on PDB-5450 Re: Slow fact queries after PuppetDB 7.9.0 upgrade when using Postgres 12 with jit enabled Dito. Thanks for swift and detailed responses. I can't say for sure. I haven't really paid any attentien to the loading time of the dashboard until it took 40 seconds. But no, I would not say it is noticeably slower. 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.434144.1643897486000.10198.1644266340297%40Atlassian.JIRA.
Jira (PDB-5450) Slow fact queries after PuppetDB 7.9.0 upgrade
Title: Message Title Elof Ofel commented on PDB-5450 Re: Slow fact queries after PuppetDB 7.9.0 upgrade Yay! Good catch! It is the JIT compilation that is the issue. echo 'jit = off' >> /var/lib/postgresql/data/pgdata/postgresql.conf After disabling it, all cells in my dashboard load in less than 3 seconds. That's ok. So if this is the solution, then your Pupperware team should disable jit in the postgres container. ...or can you see why Postgres's planner is getting such a wrong estimate? Perhaps it can be solved in pupperware with something like this: pupperware: gem/lib/pupperware/compose-services/postgres-custom/10-postgresql.conf_disable_jit.sh : #!/bin/bash /bin/grep -q '^jit = off$' /var/lib/postgresql/data/pgdata/postgresql.conf || /bin/echo -e '\n# Added by 10-postgresql.conf_disable_jit.sh:\njit = off' >> /var/lib/postgresql/data/pgdata/postgresql.conf Unfortunately I can't test the script, 'cause the official postgres docker image don't support advanced customization of the config. :-/ The script that allow customization only do this once, if there are no database. If a database already exists, all custom initialization scripts are skipped. Since I already have a database, my script (/docker-entrypoint-initdb.d/10-postgresql.conf_disable_jit.sh inside the container) is not executed. I guess that the above script will execute on a brand new pupperware install though, disabling JIT. In my case, I manually edit the postgresql.conf file and add 'jit = off'. Fortunately, this conf file is stored in a persistent docker volume, so you only need to edit it once. Add Comment
Jira (PDB-5450) Slow fact queries after PuppetDB 7.9.0 upgrade
Title: Message Title Elof Ofel commented on PDB-5450 Re: Slow fact queries after PuppetDB 7.9.0 upgrade Thanks. Will test next week. Meanwhile, I can inform you that the postgres container has not changed. During the last year or two, Pupperware has been using the container 'postgres:12.6'. So "unfortunately" your explaination above is not the reason for the performance degregation after upgrading PuppetDB from 7.8.0 to 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.434144.1643897486000.9555.1644081240031%40Atlassian.JIRA.
Jira (PDB-5450) Slow fact queries after PuppetDB 7.9.0 upgrade
Title: Message Title Elof Ofel commented on PDB-5450 Re: Slow fact queries after PuppetDB 7.9.0 upgrade Hi! Thanks (again) for quick response! I will try this next week when back at work. Can I ask for the configuration line to add/remove? PS: I'm using the standard postgres container with default settings, as installed by your Pupperware. 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.434144.1643897486000.9550.1644054540038%40Atlassian.JIRA.
Jira (PDB-5450) Slow fact queries after PuppetDB 7.9.0 upgrade
Title: Message Title Elof Ofel commented on PDB-5450 Re: Slow fact queries after PuppetDB 7.9.0 upgrade # cat /tmp/load.txt QUERY PLAN - - Aggregate (cost=76757874.40..76757874.41 rows=1 width=8) (actual time=17384.424..17384.445 rows=1 loops=1) Buffers: shared hit=3038 -> Nested Loop Semi Join (cost=1493157.16..76757874.00 rows=32 width=299) (actual time=16595.373..17384.369 rows=63 loops=1) Join Filter: (certnames.certname = fs.certname) Buffers: shared hit=3038 -> Nested Loop Semi Join (cost=747602.50..38819975.28 rows=32 width=50) (actual time=16594.563..16840.309 rows=63 loops=1)
Jira (PDB-5450) Slow fact queries after PuppetDB 7.9.0 upgrade
Title: Message Title Elof Ofel commented on PDB-5450 Re: Slow fact queries after PuppetDB 7.9.0 upgrade I now add "EXPLAIN (ANALYZE, BUFFERS)" to the query. time psql -f /tmp/q2.txt puppetdb puppetdb > /tmp/idle.txt real 0m1.036s user 0m0.035s sys 0m0.004s Works fine. I now generate some background load by reloading the dashboard and immediately re-run the command: time psql -f /tmp/q2.txt puppetdb puppetdb > /tmp/load.txt real 0m18.966s user 0m0.049s sys 0m0.013s Still works fine, only this query takes 18 seconds. Meanwhile the dashboard webpage keeps loading for ca 20 seconds more, and then display values in all cells. If I diff idle.txt and load.txt, both show the same 128 rows, just different timings. So my guess is that it is not the query(s) itself that need debugging but why a PuppetDB 7.9.0 under load start having the 40 second problems when none of the previous versions had this problem. # cat /tmp/idle.txt QUERY PLAN - - Aggregate (cost=76757873.32..76757873.33 rows=1 width=8) (actual time=924.199..924.215 rows=1 loops=1) Buffers: shared hit=3037 -> Nested Loop Semi Join (cost=1493156.08..76757872.92 rows=32 width=299) (actual time=881.713..924.189 rows=63 loops=1) Join Filter: (certnames.certname
Jira (PDB-5450) Slow fact queries after PuppetDB 7.9.0 upgrade
Title: Message Title
Elof Ofel commented on PDB-5450
Re: Slow fact queries after PuppetDB 7.9.0 upgrade
Ok, so I exec:ed into the container and added 'log_min_duration_statement = 2' to postgresql.conf and restarted. Now the postgres-container logs slow queries. Here is a spot sample. This query is generated by a PuppetExplorer dashboard cell showing how many Debian 11 nodes I have, i.e. the query: operatingsystemrelease~"^11." and operatingsystem="Debian" This generates this log while the loading of the dashboard page timeout: postgres_1 | 2022-02-04 16:40:58.161 CET [75] LOG: duration: 23246.062 ms execute /C_2: SELECT COUNT AS result_count FROM (WITH inactive_nodes AS (SELECT certname FROM certnames WHERE (deactivated IS NOT NULL AND deactivated > '2022-01-21T15:40:33.691Z') OR (expired IS NOT NULL and expired > '2022-01-21T15:40:33.691Z')), not_active_nodes AS (SELECT certname FROM certnames WHERE (deactivated IS NOT NULL OR expired IS NOT NULL)) SELECT reports.corrective_change AS "latest_report_corrective_change", certnames.deactivated AS "deactivated", certnames.expired AS "expired", reports_environment.environment AS "report_environment", certnames.certname AS "certname", fs.timestamp AS "facts_timestamp", facts_environment.environment AS "facts_environment", reports.cached_catalog_status AS "cached_catalog_status", report_statuses.status AS "latest_report_status", encode(reports.hash::bytea, 'hex') AS "latest_report_hash", catalogs.timestamp AS "catalog_timestamp", reports.noop_pending AS "latest_report_noop_pending", reports.end_time AS "report_timestamp", reports.noop AS "latest_report_noop", catalog_environment.environment AS "catalog_environment", reports.job_id AS "latest_report_job_id" FROM certnames LEFT JOIN catalogs ON catalogs.certname = certnames.certname LEFT JOIN factsets fs ON certnames.certname = fs.certname LEFT JOIN reports ON (certnames.certname = reports.certname AND certnames.latest_report_id = reports.id) LEFT JOIN environments catalog_environment ON catalog_environment.id = catalogs.environment_id LEFT JOIN report_statuses ON reports.status_id = report_statuses.id LEFT JOIN environments facts_environment ON facts_environment.id = fs.environment_id LEFT JOIN environments reports_environment ON reports_environment.id = reports.environment_id WHERE certnames.certname) in (SELECT certname FROM ( (SELECT fc.certname AS "certname" FROM (select certname, flattened.* from factsets fs left join lateral ( with recursive flattened_one (parent_path, parent_types, key, value, type) as ( select array[]::text[], '', (jsonb_each(fs.stable||fs.volatile)).*, 's' union all select parent_path || flattened_one.key, parent_types || flattened_one.type, sub_paths.key, sub_paths.value, sub_paths.type from flattened_one inner join lateral ( select (jsonb_each(value)).*, 's' as type where jsonb_typeof(value) = 'object' union all select generate_series::text as key, value->generate_series as value, 'i' as type from generate_series(0, jsonb_array_length(value) - 1) where jsonb_typeof(value) = 'array' ) as sub_paths on true ) select environment_id, parent_path || key as path, parent_types || type as types, coalesce(parent_path[1], key) as name, value from flattened_one where not jsonb_typeof(value) = any(' {"array", "object"}') ) as flattened on true) fc LEFT JOIN environments env ON fc.environment_id = env.id WHERE ((fc.path = (array['operatingsystemrelease']) and fc.types = 's') AND (value#>>'{}')::text ~ $1)) ) sub)) AND ((certnames.certname) in (SELECT certname FROM ( (SELECT fc.certname AS "certname" FROM (select certname, flattened.* from factsets fs left join lateral ( with recursive flattened_one
Jira (PDB-5259) Attempt to improve fact-contents endpoint performance
Title: Message Title Elof Ofel commented on PDB-5259 Re: Attempt to improve fact-contents endpoint performance Please see PDB-5450 if this ticket is the reason for the degregation. 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.414907.1631116164000.8025.1643899980034%40Atlassian.JIRA.
Jira (PDB-5450) PuppetDB 7.9.0 really slow
Title: Message Title
Elof Ofel updated an issue
PuppetDB / PDB-5450
PuppetDB 7.9.0 really slow
Change By:
Elof Ofel
This is a pretty vague report, I know, but I file it anyhow.I'm running PuppetDB (and puppetserver and puppetexplorer) as a docker container, managed via pupperware.I just upgraded the PuppetDB container from v7.8.0 to v7.9.0.After that, querys from PuppetExplorer are *really* slow. Sometimes they even timeout.All the cells in the PuppetExplorer dashboard usually update quickly (less than 1 second) for the last year during various PuppetDB 7.x.x versions.Now when I reload the dashboard, a few cells immediately show a value while the others show the rotating animation, waiting for a response. After 40 seconds they finally show a value (and sometimes is times out completely and an error page is displayed).In the PuppetDB container I see no warnings in the log.In the PuppetExplorer container I see no warnings if there is a response (after ~40s), otherwise it logs this (and my browser show a red puppetexplorer timeout page):{noformat}puppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceled{noformat}I'm running 'top' on the docker host.I reload the PuppetExplorer dashboard (and it sends a bunch of querys to PDB).In 'top' I can see how ca 20 postgres processes appear and each use 10% CPU.The processes are present for ~40 seconds and then disappear. At the same time my browser finally show values in all dashboard cells.So, my guess is that something in those postgres threads take 40 seconds before they finally return.The question is what.(Let me know if I can help debugging this somehow)Meanwhile, all puppet agents speak to the puppetserver as usual - no increase in the time to apply the catalog, and the server replaces the facts and stores the reports to PuppetDB without problem.In https://puppet.com/docs/puppetdb/7/release_notes.html#puppetdb-790 I see:"Improved performance of the fact-contents endpoint. Testing against a database of 10,000 mocked nodes, there was an
Jira (PDB-5450) PuppetDB 7.9.0 really slow
Title: Message Title
Elof Ofel updated an issue
PuppetDB / PDB-5450
PuppetDB 7.9.0 really slow
Change By:
Elof Ofel
This is a pretty vague report, I know, but I file it anyhow.I'm running PuppetDB (and puppetserver and puppetexplorer) as a docker container, managed via pupperware.I just upgraded the PuppetDB container from v7.8.0 to v7.9.0.After that, querys from PuppetExplorer are *really* slow. Sometimes they even timeout.All the cells in the PuppetExplorer dashboard usually update quickly (less than 1 second) for the last year during various PuppetDB 7.x.x versions.Now when I reload the dashboard, a few cells immediately show a value while the others show the rotating animation , waiting for a response. After 40 seconds they finally show a value (and sometimes it is times out completely and an error page is displayed ).In the PuppetDB container I see no warnings in the log.In the PuppetExplorer container I see no warnings if there is a response (after ~40s), otherwise it logs this (and my browser show a red puppetexplorer timeout page) :{noformat}puppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceled{noformat}I'm running 'top' on the docker host.I reload the PuppetExplorer dashboard (and it sends a bunch of querys to PDB).In 'top' I can see how ca 20 postgres processes appear and each use 10% CPU.The processes are there present for ~40 seconds and then disappear. At the same time my browser finally show values in all dashboard cells.So, my guess is that something in those postgres threads take 40 seconds before they finally return. The question is what. (Let me know if I can help debugging this somehow) Meanwhile, the all puppet agents speak to the puppetserver as usual - no increase in the time to apply the catalog, and the server replaces the facts and stores the reports to PuppetDB without problem.In https://puppet.com/docs/puppetdb/7/release_notes.html#puppetdb-790 I see:"Improved performance of the fact-contents endpoint. Testing against a database of
Jira (PDB-5450) PuppetDB 7.9.0 really slow
Title: Message Title
Elof Ofel updated an issue
PuppetDB / PDB-5450
PuppetDB 7.9.0 really slow
Change By:
Elof Ofel
This is a pretty vague report, I know, but I file it anyhow.I'm running PuppetDB (and puppetserver and puppetexplorer) as a docker container, managed via pupperware.I just upgraded the PuppetDB container from v7.8.0 to v7.9.0.After that, querys from PuppetExplorer are *really* slow. Sometimes they even timeout.All the cells in the PuppetExplorer dashboard usually update quickly (less than 1 second) for the last year during various PuppetDB 7.x.x versions. If Now when I now reload the dashboard, a few cells immediately show a value while the others show the rotating animation waiting for a response. After 40 seconds they finally show a value (and sometimes it times out completely).In the PuppetDB container I see no warnings in the log.In the PuppetExplorer container I see no warnings if there is a response (after ~40s), otherwise it logs:{noformat}puppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceled{noformat}I'm running 'top' on the docker host.I reload the PuppetExplorer dashboard (and it sends a bunch of querys to PDB).In 'top' I can see how ca 20 postgres processes appear and each use 10% CPU.The processes are there for ~40 seconds and then disappear. At the same time my browser finally show values in all dashboard cells.So, my guess is that something in those postgres threads take 40 seconds before they finally return.Meanwhile, the puppet agents speak to the puppetserver as usual - no increase in the time to apply the catalog, and the server replaces the facts and stores the reports to PuppetDB without problem.In https://puppet.com/docs/puppetdb/7/release_notes.html#puppetdb-790 I see:"Improved performance of the fact-contents endpoint. Testing against a database of 10,000 mocked nodes, there was an observed 84% decrease in time taken to complete a difficult query. https://tickets.puppetlabs.com/browse/PDB-5259"Could it be this change that degraded the
Jira (PDB-5450) PuppetDB 7.9.0 really slow
Title: Message Title
Elof Ofel updated an issue
PuppetDB / PDB-5450
PuppetDB 7.9.0 really slow
Change By:
Elof Ofel
This is a pretty vague report, I know, but I file it anyhow.I'm running PuppetDB ( an and puppetserver and puppetexplorer) as a docker container, managed via pupperware.I just upgraded the PuppetDB container from v7.8.0 to v7.9.0.After that, querys from PuppetExplorer are *really* slow. Sometimes they even timeout.All the cells in the PuppetExplorer dashboard usually update quickly (less than 1 second) for the last year during various PuppetDB 7.x.x versions.If I now reload the dashboard, a few cells immediately show a value while the others show the rotating animation waiting for a response. After 40 seconds they finally show a value (and sometimes it times out completely).In the PuppetDB container I see no warnings in the log.In the PuppetExplorer container I see no warnings if there is a response (after ~40s), otherwise it logs:{noformat}puppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceledpuppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceled{noformat}I'm running 'top' on the docker host.I reload the PuppetExplorer dashboard (and it sends a bunch of querys to PDB).In 'top' I can see how ca 20 postgres processes appear and each use 10% CPU.The processes are there for ~40 seconds and then disappear. At the same time my browser finally show values in all dashboard cells.So, my guess is that something in those postgres threads take 40 seconds before they finally return.Meanwhile, the puppet agents speak to the puppetserver as usual - no increase in the time to apply the catalog, and the server replaces the facts and stores the reports to PuppetDB without problem.In https://puppet.com/docs/puppetdb/7/release_notes.html#puppetdb-790 I see:"Improved performance of the fact-contents endpoint. Testing against a database of 10,000 mocked nodes, there was an observed 84% decrease in time taken to complete a difficult query. https://tickets.puppetlabs.com/browse/PDB-5259"Could it be this change that degraded the
Jira (PDB-5450) PuppetDB 7.9.0 really slow
Title: Message Title Elof Ofel created an issue PuppetDB / PDB-5450 PuppetDB 7.9.0 really slow Issue Type: Task Affects Versions: PDB 7.9.0 Assignee: Unassigned Components: PuppetDB Created: 2022/02/03 6:11 AM Priority: Normal Reporter: Elof Ofel This is a pretty vague report, I know, but I file it anyhow. I'm running PuppetDB (an puppetserver and puppetexplorer) as a docker container, managed via pupperware. I just upgraded the PuppetDB container from v7.8.0 to v7.9.0. After that, querys from PuppetExplorer are really slow. Sometimes they even timeout. All the cells in the PuppetExplorer dashboard usually update quickly (less than 1 second) for the last year during various PuppetDB 7.x.x versions. If I now reload the dashboard, a few cells immediately show a value while the others show the rotating animation waiting for a response. After 40 seconds they finally show a value (and sometimes it times out completely). In the PuppetDB container I see no warnings in the log. In the PuppetExplorer container I see no warnings if there is a response (after ~40s), otherwise it logs: puppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502 /api/pdb/query/v4/nodes] context canceled puppetexplorer_1 | 03/Feb/2022:12:57:48 + [ERROR 502
Jira (PDB-4876) Metrics endpoint broken
Title: Message Title Elof Ofel commented on PDB-4876 Re: Metrics endpoint broken Confirmed in the open-source version (in this case, puppetdb 5.2.15-1stretch). #grep ^CONFIG /etc/default/puppetdb CONFIG="/etc/puppetlabs/puppetdb/conf.d" I created the metrics.conf file above in this dir and ran 'systemctl restart puppetdb'. Now the v1 endpoint respond to queries again. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PDB-4876) Metrics endpoint broken
Title: Message Title Elof Ofel commented on PDB-4876 Re: Metrics endpoint broken Thanks for your excellent answers! For completeness, I plan to test the above metrics.conf file in an open source Puppet, tomorrow or next week. 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.370980.1599053609000.33141.1599688440622%40Atlassian.JIRA.
Jira (PDB-4876) Metrics endpoint broken
Title: Message Title Elof Ofel commented on PDB-4876 Re: Metrics endpoint broken Hi Zachary Kent ! Thanks for this response. That explains it all. A manual test confirms what you wrote: http://localhost:8080/metrics/v2/read/puppetlabs.puppetdb.population:name=pct-resource-dupesrequest mbean "puppetlabs.puppetdb.population:name=pct-resource-dupes" type "read" value Value "151107/183659" timestamp 1599214647 status 200 The v2 metrics endpoint is working fine. Yes, updating the docs would help others in the same situation like me. Nowhere did I see any mention of v1 being disabled. For completeness in this ticket (and possibly also in your updated documentation), can you please add instructions on how to force the v1 endpoint back on? Add Comment
Jira (PDB-4876) Metrics endpoint broken
Title: Message Title
Elof Ofel updated an issue
PuppetDB / PDB-4876
Metrics endpoint broken
Change By:
Elof Ofel
Strange bug: After I upgraded puppetdb from 5.2.12-1stretch to 5.2.15-1stretch, I can no longer access the metrics endpoint.All requests to /metrics/v1/mbeans/* get at "404 not found" response while requests to e.g. /pdb/query/v4/ work just fine (200 OK). Prior to Jun 30, my system (Debian 9) was running puppetdb 5.2.12-1stretch and everything was working fine.On Jun 30, an 'apt-get upgrade' upgraded puppet-agent, puppet5-release, puppetdb, puppetserver and puppetdb-termini:{noformat} dpkg.log.3.gz:2020-06-30 08:34:48 upgrade puppet-agent:amd64 5.5.18-1stretch 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:48 status half-configured puppet-agent:amd64 5.5.18-1stretchdpkg.log.3.gz:2020-06-30 08:34:48 status unpacked puppet-agent:amd64 5.5.18-1stretchdpkg.log.3.gz:2020-06-30 08:34:48 status half-installed puppet-agent:amd64 5.5.18-1stretchdpkg.log.3.gz:2020-06-30 08:34:50 status half-installed puppet-agent:amd64 5.5.18-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 configure puppet-agent:amd64 5.5.20-1stretch dpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64 5.5.20-1stretchdpkg.log.3.gz:2020-06-30 08:34:51 status unpacked puppet-agent:amd64
Jira (PDB-4876) Metrics endpoint broken
Title: Message Title Elof Ofel created an issue PuppetDB / PDB-4876 Metrics endpoint broken Issue Type: Bug Affects Versions: PDB 5.2.15 Assignee: Unassigned Components: PuppetDB Created: 2020/09/02 6:33 AM Environment: Debian 9 puppet-agent 5.5.20-1stretch amd64 puppet5-release 5.0.0-11stretch all puppetdb 5.2.15-1stretch all puppetdb-termini 5.2.15-1stretch all puppetexplorer 2.0.0-62 all puppetserver 5.3.13-1stretch all ruby-puppet-forge 2.2.2-2 all ruby-semantic-puppet 0.1.4-2 all Labels: metrics Priority: Normal Reporter: Elof Ofel Strange bug: After I upgraded puppetdb from 5.2.12-1stretch to 5.2.15-1stretch, I can no longer access the metrics endpoint. All requests to /metrics/v1/mbeans/* get at "404 not found" response while requests to e.g. /pdb/query/v4/ work just fine (200 OK). Prior to Jun 30, my system (Debian 9) was running puppetdb 5.2.12-1stretch and everything was working fine. On Jun 30, an 'apt-get upgrade' upgraded puppet-agent, puppet5-release, puppetdb, puppetserver and puppetdb-termini:
Jira (PUP-9316) implement no_proxy in puppet.conf
Title: Message Title Elof Ofel commented on PUP-9316 Re: implement no_proxy in puppet.conf Actually, the problem here was that puppet 5.5.16 and prior versions did not work in the manner the manual stated. The manual for http_proxy_host says "Environment variable http_proxy or HTTP_PROXY will override this value" but apparently it never did. But now in 5.5.17 this is fixed. So this discussion doesn't really have to do explicitly with the 'no_proxy' variable, but rather with the rest of the environment variable handling that was changed in the commit. In my case this fix became a major problem even though it was just a minor version upgrade. Some logs just because you asked for them: I have the new version 5.5.17: # dpkg -l | grep puppet ii puppet-agent
Jira (PUP-9316) implement no_proxy in puppet.conf
Title: Message Title Elof Ofel commented on PUP-9316 Re: implement no_proxy in puppet.conf When I upgraded from 5.5.16 to 5.5.17, puppet stopped working on all my Debian 9 machines. (haven't tried on any others yet) I think it has to do with this change. # env | grep -i proxy no_proxy=localhost,127.0.0.1 HTTP_PROXY=http://10.x.x.x:3128/ FTP_PROXY=http://10.x.x.x:3128/ https_proxy=http://10.x.x.x:3128/ http_proxy=http://10.x.x.x:3128/ HTTPS_PROXY=http://10.x.x.x:3128/ ftp_proxy=http://10.x.x.x:3128/ # puppet agent -t --noop Warning: Unable to fetch my node definition, but the agent run will continue: Warning: 403 "Forbidden" Info: Retrieving pluginfacts
Jira (PUP-7779) Re-implement `puppet facts upload` and associated server endpoint
Title: Message Title Elof Ofel commented on PUP-7779 Re: Re-implement `puppet facts upload` and associated server endpoint +1 I really wanted to vote for PUP-5934 , but it's been closed in favor for this ticket. I don't need a real-time sync of the facts. I simply need the facts to be executed again after the puppet run, and attached to the report back to puppetDB. That's it. Then my queries to PuppetDB will show the current and correct state of the node. Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- 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 (FACT-1746) virtual and is_virtual are reported incorrectly on freebsd proxmox vms
Title: Message Title Elof Ofel commented on FACT-1746 Re: virtual and is_virtual are reported incorrectly on freebsd proxmox vms Need I do something more on this ticket? Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- 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 (FACT-1746) virtual and is_virtual are reported incorrectly on freebsd proxmox vms
Title: Message Title Elof Ofel commented on FACT-1746 Re: virtual and is_virtual are reported incorrectly on freebsd proxmox vms I did it. Made a patch and tested it. Works fine. Created a PR - https://github.com/puppetlabs/facter/pull/1639 Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- 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 (FACT-1746) virtual and is_virtual are reported incorrectly on freebsd proxmox vms
Title: Message Title Elof Ofel commented on FACT-1746 Re: virtual and is_virtual are reported incorrectly on freebsd proxmox vms Michael Smith, thanks for your help on FACT-1744. Perhaps you can help me with this one too? The changes needed here aren't as easy as exchangeing a single word, so my devel-skills are wy too poor to even make an attempt and test the port on a FreeBSD machine. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- 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 (FACT-1746) virtual and is_virtual are reported incorrectly on freebsd proxmox vms
Title: Message Title Elof Ofel updated an issue Facter / FACT-1746 virtual and is_virtual are reported incorrectly on freebsd proxmox vms Change By: Elof Ofel Environment: VM (kvm / qemu) running on a Proxmox host.The VM is running FreeBSD 10.3 amd64.Puppet4 (from FreeBSD ports) is compiled with facter 3.8.0. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- 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 (FACT-1746) virtual and is_virtual are reported incorrectly on freebsd proxmox vms
Title: Message Title Elof Ofel created an issue Facter / FACT-1746 virtual and is_virtual are reported incorrectly on freebsd proxmox vms Issue Type: Bug Affects Versions: FACT 3.8.0 Assignee: Unassigned Created: 2017/09/07 6:46 AM Environment: FreeBSD 10.3 amd64. Puppet4 compiled with facter 3.8.0. Priority: Major Reporter: Elof Ofel Before I upgraded from facter 2.5.0 to 3.8.0, I had: virtual kvm is_virtual true
Jira (FACT-1744) kenv lookup for smbios.system.serial failed on FreeBSD
Title: Message Title Elof Ofel commented on FACT-1744 Re: kenv lookup for smbios.system.serial failed on FreeBSD I'm no programmer, but created a PR: https://github.com/puppetlabs/facter/pull/1637 Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- 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 (FACT-1744) kenv lookup for smbios.system.serial failed on FreeBSD
Title: Message Title Elof Ofel created an issue Facter / FACT-1744 kenv lookup for smbios.system.serial failed on FreeBSD Issue Type: Bug Affects Versions: FACT 3.8.0 Assignee: Unassigned Created: 2017/09/04 8:39 AM Environment: FreeBSD 10.3 amd64 running as a VM on a proxmox host. puppet4 (from ports. In its make options I changed from ruby-facter-2.x to c-facter-3.x) facter 3.8.0 Priority: Normal Reporter: Elof Ofel When I run facter -p I always get an error message (apart from the normal output): Warning: Facter: kenv lookup for smbios.system.serial failed: No such file or directory (2) Running facter -d -p
Jira (FACT-1736) EC2 fact hangs for 10 minutes trying to reach 169.254.169.254
Title: Message Title Elof Ofel commented on FACT-1736 Re: EC2 fact hangs for 10 minutes trying to reach 169.254.169.254 I see that there are also a port for facter 3.8.0. Is that one better? (In the make options for puppet4 I see that I can change the dependency: CFACTER=off: Use facter 3.x (experimental rewrite in C++) RFACTER=on: Use facter 2.x (written in Ruby) ) Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- 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 (FACT-1736) EC2 fact hangs for 10 minutes trying to reach 169.254.169.254
Title: Message Title Elof Ofel created an issue Facter / FACT-1736 EC2 fact hangs for 10 minutes trying to reach 169.254.169.254 Issue Type: Bug Assignee: Unassigned Created: 2017/08/22 9:35 AM Environment: FreeBSD 10.3 with the latest ports: rubygem-facter 2.5.0 ruby 2.3.4_2,1 puppet4 4.10.6 Labels: ec2 Priority: Major Reporter: Elof Ofel Many firewalls block and drop packets for non-allowed traffic. This mean that no RST response is sent back to the client to terminate the connection attempt. Puppet nodes placed behind such a firewall send TCP SYN packets to 169.254.169.254:80 over and over and over again due to the EC2 fact. A single puppet run that normally takes 10 seconds now takes more than 10 minutes! That's why I set this issue type as Bug and not Improvement. My current workaround is to configure an alias IP 169.254.169.254 on a local interface on the nodes, or setup a REJECT-rule in my firewall, so the connection attempts are terminated immediately and EC2 can continue.
Jira (PDB-3063) latest_report_noop_pending=null, should be =true
Title: Message Title Elof Ofel commented on PDB-3063 Re: latest_report_noop_pending=null, should be =true This ticket can be closed if you choose to ignore the changed logic, and instead urge users to upgrade and then use the new syntax in their queries. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- 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-3063) latest_report_noop_pending=null, should be =true
Title: Message Title
Elof Ofel commented on PDB-3063
Re: latest_report_noop_pending=null, should be =true
Wyatt Alt, Ah. Testing. Yes, from an updated Debian client (puppet agent --version: 4.6.2), I get "latest_report_noop" : true, "latest_report_noop_pending" : true, "latest_report_status" : "unchanged"
The 'null' values in my original post came from a FreeBSD client with v4.5.1. So, once all my clients are updated I can start using latest_report_noop_pending. Great.
—
Regarding section #2:
Prior to PuppetDB v4.2:
The query #report { latest_report?=true and noop=true and status="unchanged" }
matches clients with pending jobs. (the last performed puppet run is a noop run, and it reported changes)
Now after PuppetDB v4.2:
The query #report { latest_report?=true and noop=true and status="unchanged" }
matches *any and all nodes* that use the new version of the puppet client, wether they have pending jobs or not.
This is possibly bad, if there are applications out there who rely on the old logic. They must update their syntax.
Jira (PDB-3063) latest_report_noop_pending=null, should be =true
Title: Message Title
Elof Ofel updated an issue
PuppetDB / PDB-3063
latest_report_noop_pending=null, should be =true
Change By:
Elof Ofel
Hmm, I think the changes with "noop_pending", intoduced in v4.2 (PDB-2753) is buggy.latest_report_noop_pending is set to null even though the last noop run showed changes.Example:On node foo.bar.com I run 'puppet agent -t --noop'.It shows me there are changes to be made.In puppetdb however, it looks like this:{noformat}curl -X GET http://127.0.0.1:8080/pdb/query/v4/nodes/foo.bar.com{ "deactivated" : null, "latest_report_hash" : "114082ba90a7a0fc94580ffa520315d8d1f2723a", "facts_environment" : "production", "cached_catalog_status" : "not_used", "report_environment" : "production", "latest_report_corrective_change" : null, "catalog_environment" : "production", "facts_timestamp" : "2016-09-21T08:33:28.459Z", "latest_report_noop" : true, "expired" : null, "latest_report_noop_pending" : null, "report_timestamp" : "2016-09-21T08:33:31.811Z", "certname" : "foo.bar.com", "catalog_timestamp" : "2016-09-21T08:33:32.601Z", "latest_report_status" : "unchanged"}{noformat}{noformat}So... "report_timestamp" : "2016-09-21T08:33:31.811Z" Correct. That's the time I ran the noop. "latest_report_noop" : true Correct, I've run nothing else after the noop. "latest_report_status" : "unchanged" Correct, nothing was changed. "latest_report_noop_pending" : null Wrong!{noformat}\\I have a cron job that periodically do a noop-run on all my nodes.For nodes that are not "up to date", I get an email report.Also, in PuppetExplorer I list these "nodes with pending jobs" using a query like this:{noformat}#report { latest_report?=true and noop=true and status="unchanged" }{noformat}Since PuppetDB 4.2, this query doesn't work any more.The problem is that neither of these querys now show me the list of nodes with pending jobs:{noformat}#node { latest_report_noop_pending=true }#report { latest_report?=true and noop_pending=true } #report { latest_report?=true and noop=true and status="unchanged" }{ noformat}Is my query wrong, or is there a bug in puppetdb?(Running the latest puppet on Debian 8.6: puppet-agent 1.6.2-1jessiepuppetdb 4.2.2-1puppetlabs1puppetdb-termini 4.2.2-1puppetlabs1puppetexplorer 2.0.0-62puppetlabs-release-pc1 1.1.0-2jessiepuppetserver 2.6.0-1puppetlabs1)
Add Comment
Jira (PDB-3063) latest_report_noop_pending=null, should be =true
Title: Message Title
Elof Ofel updated an issue
PuppetDB / PDB-3063
latest_report_noop_pending=null, should be =true
Change By:
Elof Ofel
Hmm, I think the changes with "noop_pending", intoduced in v4.2 (PDB-2753) is buggy.latest_report_noop_pending is set to null even though the last noop run showed changes.Example:On node foo.bar.com I run 'puppet agent -t --noop'.It shows me there are changes to be made.In puppetdb however, it looks like this:{noformat}curl -X GET http://127.0.0.1:8080/pdb/query/v4/nodes/foo.bar.com{ "deactivated" : null, "latest_report_hash" : "114082ba90a7a0fc94580ffa520315d8d1f2723a", "facts_environment" : "production", "cached_catalog_status" : "not_used", "report_environment" : "production", "latest_report_corrective_change" : null, "catalog_environment" : "production", "facts_timestamp" : "2016-09-21T08:33:28.459Z", "latest_report_noop" : true, "expired" : null, "latest_report_noop_pending" : null, "report_timestamp" : "2016-09-21T08:33:31.811Z", "certname" : "foo.bar.com", "catalog_timestamp" : "2016-09-21T08:33:32.601Z", "latest_report_status" : "unchanged"}{noformat}{noformat}So... "report_timestamp" : "2016-09-21T08:33:31.811Z" Correct. That's the time I ran the noop. "latest_report_noop" : true Correct, I've run nothing else after the noop. "latest_report_status" : "unchanged" Correct, nothing was changed. "latest_report_noop_pending" : null Wrong!{noformat} \\ \\ \\ I have a cron job that periodically do a noop-run on all my nodes.For nodes that are not "up to date", I get an email report.Also, in PuppetExplorer I list these "nodes with pending jobs" using a query like this:{noformat}#report { latest_report?=true and noop=true and status="unchanged" }{noformat}Since PuppetDB 4.2, this query doesn't work any more.The problem is that neither of these querys now show me the list of nodes with pending jobs:{noformat}#node { latest_report_noop_pending=true }#report { latest_report?=true and noop_pending=true }{noformat} \\ \\ Is my query wrong, or is there a bug in puppetdb?(Running the latest puppet on Debian 8.6: puppet-agent 1.6.2-1jessiepuppetdb 4.2.2-1puppetlabs1puppetdb-termini 4.2.2-1puppetlabs1puppetexplorer 2.0.0-62puppetlabs-release-pc1 1.1.0-2jessiepuppetserver 2.6.0-1puppetlabs1)
Add Comment
Jira (PDB-3063) latest_report_noop_pending=null, should be =true
Title: Message Title
Elof Ofel updated an issue
PuppetDB / PDB-3063
latest_report_noop_pending=null, should be =true
Change By:
Elof Ofel
Hmm, I think the changes with "noop_pending", intoduced in v4.2 (PDB-2753) is buggy.latest_report_noop_pending is set to null even though the last noop run showed changes.Example:On node foo.bar.com I run 'puppet agent -t --noop'.It shows me there are changes to be made.In puppetdb however, it looks like this:{noformat}curl -X GET http://127.0.0.1:8080/pdb/query/v4/nodes/foo.bar.com{ "deactivated" : null, "latest_report_hash" : "114082ba90a7a0fc94580ffa520315d8d1f2723a", "facts_environment" : "production", "cached_catalog_status" : "not_used", "report_environment" : "production", "latest_report_corrective_change" : null, "catalog_environment" : "production", "facts_timestamp" : "2016-09-21T08:33:28.459Z", "latest_report_noop" : true, "expired" : null, "latest_report_noop_pending" : null, "report_timestamp" : "2016-09-21T08:33:31.811Z", "certname" : "foo.bar.com", "catalog_timestamp" : "2016-09-21T08:33:32.601Z", "latest_report_status" : "unchanged"}{noformat}{noformat}So... "report_timestamp" : "2016-09-21T08:33:31.811Z" Correct. That's the time I ran the noop. "latest_report_noop" : true Correct, I've run nothing else after the noop. "latest_report_status" : "unchanged" Correct, nothing was changed. "latest_report_noop_pending" : null Wrong!{noformat} I have a cron job that periodically do a noop-run on all my nodes.For nodes that are not "up to date", I get an email report.Also, in PuppetExplorer I list these "nodes with pending jobs" using a query like this:{noformat}#report { latest_report?=true and noop=true and status="unchanged" }{noformat}Since PuppetDB 4.2, this query doesn't work any more.The problem is that neither of these querys now show me the list of nodes with pending jobs:{noformat}#node { latest_report_noop_pending=true }#report { latest_report?=true and noop_pending=true }{noformat}Is my query wrong, or is there a bug in puppetdb?(Running the latest puppet on Debian 8.6: puppet-agent 1.6.2-1jessiepuppetdb 4.2.2-1puppetlabs1puppetdb-termini 4.2.2-1puppetlabs1puppetexplorer 2.0.0-62puppetlabs-release-pc1 1.1.0-2jessiepuppetserver 2.6.0-1puppetlabs1)
Add Comment
Jira (PDB-3063) latest_report_noop_pending=null, should be =true
Title: Message Title
Elof Ofel updated an issue
PuppetDB / PDB-3063
latest_report_noop_pending=null, should be =true
Change By:
Elof Ofel
Hmm, I think the changes with "noop_pending", intoduced in v4.2 (PDB-2753) is buggy.latest_report_noop_pending is set to null even though the last noop run showed changes.Example:On node foo.bar.com I run 'puppet agent -t --noop'.It shows me there are changes to be made.In puppetdb however, it looks like this:{noformat}curl -X GET http://127.0.0.1:8080/pdb/query/v4/nodes/foo.bar.com{ "deactivated" : null, "latest_report_hash" : "114082ba90a7a0fc94580ffa520315d8d1f2723a", "facts_environment" : "production", "cached_catalog_status" : "not_used", "report_environment" : "production", "latest_report_corrective_change" : null, "catalog_environment" : "production", "facts_timestamp" : "2016-09-21T08:33:28.459Z", "latest_report_noop" : true, "expired" : null, "latest_report_noop_pending" : null, "report_timestamp" : "2016-09-21T08:33:31.811Z", "certname" : "foo.bar.com", "catalog_timestamp" : "2016-09-21T08:33:32.601Z", "latest_report_status" : "unchanged"}{noformat}{noformat}So... "report_timestamp" : "2016-09-21T08:33:31.811Z" Correct. That's the time I ran the noop. "latest_report_noop" : true Correct, I've run nothing else after the noop. "latest_report_status" : "unchanged" Correct, nothing was changed. "latest_report_noop_pending" : {color:red} null {color} Wrong!{noformat}I have a cron job that periodically do a noop-run on all my nodes.For nodes that are not "up to date", I get an email report.Also, in PuppetExplorer I list these "nodes with pending jobs" using a query like this:{noformat}#report { latest_report?=true and noop=true and status="unchanged" }{noformat}Since PuppetDB 4.2, this query doesn't work any more.The problem is that neither of these querys now show me the list of nodes with pending jobs:{noformat}#node { latest_report_noop_pending=true }#report { latest_report?=true and noop_pending=true }{noformat}Is my query wrong, or is there a bug in puppetdb?(Running the latest puppet on Debian 8.6: puppet-agent 1.6.2-1jessiepuppetdb 4.2.2-1puppetlabs1puppetdb-termini 4.2.2-1puppetlabs1puppetexplorer 2.0.0-62puppetlabs-release-pc1 1.1.0-2jessiepuppetserver 2.6.0-1puppetlabs1)
Add Comment
Jira (PDB-3063) latest_report_noop_pending=null, should be =true
Title: Message Title Elof Ofel created an issue PuppetDB / PDB-3063 latest_report_noop_pending=null, should be =true Issue Type: Bug Affects Versions: PDB 4.2.2 Assignee: Unassigned Components: PuppetDB Created: 2016/09/21 3:27 AM Priority: Normal Reporter: Elof Ofel Hmm, I think the changes with "noop_pending", intoduced in v4.2 ( PDB-2753 ) is buggy. latest_report_noop_pending is set to null even though the last noop run showed changes. Example: On node foo.bar.com I run 'puppet agent -t --noop'. It shows me there are changes to be made. In puppetdb however, it looks like this: curl -X GET http://127.0.0.1:8080/pdb/query/v4/nodes/foo.bar.com
Jira (PUP-4387) Cyan colored notices
Title: Message Title Elof Ofel commented on PUP-4387 Re: Cyan colored notices I haven't lived without color since I just upgraded from v2.7... But I must say that I do like colorizing the output. Being able to instantly visually separate different sections from each other is quite important. I like the cyan color, so I'd like it back. A bit off topic: Perhaps because I've made a separate script just for running --noop to swiftly see what's going to be modified on the machine, I like cyan back. The script removes all uninteresting lines and then add some extra colorization to keywords making you instantly see what parameters are being modified by just skimming through the --noop output. In my script, all diffs begin with a 3-line yellow separator, then the diff itself uses red lines for old data and white lines (with a green '+' at the beginning). Having white and red text for diff-data and cyan for notices vastly improves the visibility and differentiates from puppet messages (in cyan) from file data. The script also print the last parameter within square brackets in magenta, followed by its modification action highlighted in yellow. Ideally, IMHO puppet should produce output like this, but I don't think that's really possible. If anyone's interested, here's my hack (you need to replace ^[ with true Esc characters...). pnoop.sh : #!/bin/sh puppet agent -t --noop | egrep -v ' Would have triggered .refresh. from|content: current_value .md5.*, should be .md5|Notice: /Stage.main.*/File.*/content: $|Notice: Augeas.*: $|Notice: /Stage.Augeas.*returns: current_value need_to_run,' | sed \ -e 's/\[\([^0][^;][^]]*\)]\([^[]*, \)\(should be [^(]*\)/[^[[35m\1^[[36m]\2^[[33m\3^[[36m/' \ -e 's/^+++ .*/^[[33m^[[0m/' \ -e 's/^--- .*/^[[33m^[[0m/' \
Jira (PUP-4387) Cyan colored notices
Title: Message Title Elof Ofel created an issue Puppet / PUP-4387 Cyan colored notices Issue Type: Bug Affects Versions: PUP 3.7.4 Assignee: Kylo Ginsberg Components: Client Created: 2015/04/09 8:33 AM Environment: FreeBSD 10.0 Labels: ANSI color Priority: Trivial Reporter: Elof Ofel Original Estimate: 1 hour Remaining Estimate: 1 hour
Jira (PUP-4387) Cyan colored notices
Title: Message Title Elof Ofel updated an issue Puppet / PUP-4387 Cyan colored notices Change By: Elof Ofel Youseemtohavemadeatypoin(atleast)puppet3.7.4.Inpuppet2.7,running'puppetagent-t--noop'producedlotsofnotice-linesincyancolor.NowthatI'veupgradedto3.7.4,thecyancolorisgone.However,whenlookingattherawtextoutput,youseestrangeANSIcodes.Info-linesarecorrectlyformatted,butallNotice-linesareincorrect.Example:Esc[0;32mInfo:LoadingfactsEsc[0mEsc[0;32mInfo:Cachingcatalogforfoo.bar.comEsc[0mEsc[0;32mInfo:Applyingconfigurationversion'1428593162'^[[0mEsc[mNotice:/Stage[main]/Foobarfiles::Home/File[/home/foo/.bashrc]/ensure:current_valueabsent,shouldbefile(noop)Esc[0mSomehowtheANSIcolorcode0;36hasdisappeared.Itshouldsay:Esc[0;36mNotice :/Stage[main]/Foobarfiles::Home/File[/home/foo/ . . bashrc]/ensure:current_valueabsent,shouldbefile(noop)Esc[0m (theendofalllines,Noticesincluded,arecorrectlyterminatedwithEsc[0m) Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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 http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4387) Cyan colored notices
Title: Message Title Elof Ofel updated an issue Puppet / PUP-4387 Cyan colored notices Change By: Elof Ofel Youseemtohavemadeatypoin(atleast)puppet3.7.4.Inpuppet2.7,running'puppetagent-t--noop'producedlotsofnotice-linesincyancolor.NowthatI'veupgradedto3.7.4,thecyancolorisgone.However,whenlookingattherawtextoutput,youseestrangeANSIcodes.Info-linesarecorrectlyformatted,butallNotice-linesareincorrect.Example:Esc[0;32mInfo:LoadingfactsEsc[0mEsc[0;32mInfo:Cachingcatalogforfoo.bar.comEsc[0mEsc[0;32mInfo:Applyingconfigurationversion'1428593162'^[[0mEsc[mNotice:/Stage[main]/Foobarfiles::Home/File[/home/foo/.bashrc]/ensure:current_valueabsent,shouldbefile(noop)Esc[0m SomehowtheANSIcolorcode0;36hasdisappeared. Itshouldsay:Esc[0;36mNotice.. SomehowtheANSIcolorcode0;36hasdisappeared. (theendofalllines,Noticesincluded,arecorrectlyterminatedwithEsc[0m) Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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 http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4387) Cyan colored notices
Title: Message Title Elof Ofel updated an issue Puppet / PUP-4387 Cyan colored notices Change By: Elof Ofel Youseemtohavemadeatypoin(atleast)puppet3.7.4.Inpuppet2.7,running'puppetagent-t--noop'producedlotsofnotice-linesincyancolor.NowthatI'veupgradedto3.7.4,thecyancolorisgone.However,whenlookingattherawtextoutput,youseestrangeANSIcodes.Info-linesarecorrectlyformatted,butallNotice-linesareincorrect.Example:Esc[0;32mInfo:LoadingfactsEsc[0mEsc[0;32mInfo:Cachingcatalogforfoo.bar.comEsc[0mEsc[0;32mInfo:Applyingconfigurationversion'1428593162'^[[0mEsc[mNotice:/Stage[main]/Foobarfiles::Home/File[/home/foo/.bashrc]/ensure:current_valueabsent,shouldbefile(noop)Esc[0mItshouldsay:Esc[0;36mNotice : .. SomehowtheANSIcolorcode0;36hasdisappeared. (theendofalllines,Noticesincluded,arecorrectlyterminatedwithEsc[0m) Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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 http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4387) Cyan colored notices
Title: Message Title Elof Ofel updated an issue Puppet / PUP-4387 Cyan colored notices Change By: Elof Ofel Youseemtohavemadeatypoin(atleast)puppet3.7.4.Inpuppet2.7,running'puppetagent-t--noop'produced lost lots ofnotice-linesincyancolor.NowthatI'veupgradedto3.7.4,thecyancolorisgone.However,whenlookingattherawtextoutput,youseestrangeANSIcodes.Info-linesarecorrectlyformatted,butallNotice-linesareincorrect.Example:Esc[0;32mInfo:LoadingfactsEsc[0mEsc[0;32mInfo:Cachingcatalogforfoo.bar.comEsc[0mEsc[0;32mInfo:Applyingconfigurationversion'1428593162'^[[0mEsc[mNotice:/Stage[main]/Foobarfiles::Home/File[/home/foo/.bashrc]/ensure:current_valueabsent,shouldbefile(noop)Esc[0mItshouldsay:Esc[0;36mNotice:(theendofalllines,Noticesincluded,arecorrectlyterminatedwithEsc[0m) Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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 http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4387) Cyan colored notices
Title: Message Title
Elof Ofel updated an issue
Puppet / PUP-4387
Cyan colored notices
Change By:
Elof Ofel
Youseemtohavemadeatypoin(atleast)puppet3.7.4.Inpuppet2.7,running'puppetagent-t--noop'producedlotsofnotice-linesincyancolor.NowthatI'veupgradedto3.7.4,thecyancolorisgone.However,whenlookingattherawtextoutput,youseestrangeANSIcodes.Info-linesarecorrectlyformatted,butallNotice-linesareincorrect.Example:{noformat}Esc[0;32mInfo:LoadingfactsEsc[0mEsc[0;32mInfo:Cachingcatalogforfoo.bar.comEsc[0mEsc[0;32mInfo:Applyingconfigurationversion'1428593162'^[[0mEsc[mNotice:/Stage[main]/ Foobarfiles Foo ::Home/File[/ home/ foo/. bashrc foo ]/ensure:current_valueabsent,shouldbefile(noop)Esc[0m{noformat}SomehowtheANSIcolorcode0;36hasdisappeared.Itshouldsay:{noformat}Esc[0;36mNotice:/Stage[main]/ Foobarfiles Foo ::Home/File[/ home/ foo/. bashrc foo ]/ensure:current_valueabsent,shouldbefile(noop)Esc[0m{noformat}(theendofalllines,Noticesincluded,arecorrectlyterminatedwithEsc[0m)
Add Comment
This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4387) Cyan colored notices
Title: Message Title
Elof Ofel updated an issue
Puppet / PUP-4387
Cyan colored notices
Change By:
Elof Ofel
Youseemtohavemadeatypoin(atleast)puppet3.7.4.Inpuppet2.7,running'puppetagent-t--noop'producedlotsofnotice-linesincyancolor.NowthatI'veupgradedto3.7.4,thecyancolorisgone.However,whenlookingattherawtextoutput,youseestrangeANSIcodes.Info-linesarecorrectlyformatted,butallNotice-linesareincorrect.Example:{noformat}Esc[0;32mInfo:LoadingfactsEsc[0mEsc[0;32mInfo:Cachingcatalogforfoo.bar.comEsc[0mEsc[0;32mInfo:Applyingconfigurationversion'1428593162'^[[0mEsc[mNotice:/Stage[main]/Foo::Home/File[/foo/ .foo x ]/ensure:current_valueabsent,shouldbefile(noop)Esc[0m{noformat}SomehowtheANSIcolorcode0;36hasdisappeared.Itshouldsay:{noformat}Esc[0;36mNotice:/Stage[main]/Foo::Home/File[/foo/ .foo x ]/ensure:current_valueabsent,shouldbefile(noop)Esc[0m{noformat}(theendofalllines,Noticesincluded,arecorrectlyterminatedwithEsc[0m)
Add Comment
This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4387) Cyan colored notices
Title: Message Title
Elof Ofel updated an issue
Puppet / PUP-4387
Cyan colored notices
Change By:
Elof Ofel
Youseemtohavemadeatypoin(atleast)puppet3.7.4.Inpuppet2.7,running'puppetagent-t--noop'producedlotsofnotice-linesincyancolor.NowthatI'veupgradedto3.7.4,thecyancolorisgone.However,whenlookingattherawtextoutput,youseestrangeANSIcodes.Info-linesarecorrectlyformatted,butallNotice-linesareincorrect.Example:{noformat}Esc[0;32mInfo:LoadingfactsEsc[0mEsc[0;32mInfo:Cachingcatalogforfoo.bar.comEsc[0mEsc[0;32mInfo:Applyingconfigurationversion'1428593162' ^ Esc [ [ 0mEsc[mNotice:/Stage[main]/Foo::Home/File[/foo/x]/ensure:current_valueabsent,shouldbefile(noop)Esc[0m ^ {noformat}SomehowtheANSIcolorcode0;36hasdisappeared. Itshouldsay:{noformat}Esc[0;36mNotice:/Stage[main]/Foo::Home/File[/foo/x]/ensure:current_valueabsent,shouldbefile(noop)Esc[0m{noformat}(theendofalllines,Noticesincluded,arecorrectlyterminatedwithEsc[0m)
Add Comment
This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4387) Cyan colored notices
Title: Message Title
Elof Ofel updated an issue
Puppet / PUP-4387
Cyan colored notices
Change By:
Elof Ofel
Youseemtohavemadeatypoinpuppet3.7.x.Inpuppet2.7,running{{puppetagent-t--noop}}producedlotsofnotice-linesincyancolor.AfterIupgradedto3.7.4,thecyancolorisgone. However,when When lookingattherawtextoutput fromthesameabovecommand ,yousee strange incomplete ANSIcodes.Info-linesarecorrectlyformatted,butallNotice-linesareincorrect.Example:{noformat}Esc[0;32mInfo:LoadingfactsEsc[0mEsc[0;32mInfo:Cachingcatalogforfoo.bar.comEsc[0mEsc[0;32mInfo:Applyingconfigurationversion'1428593162'Esc[0mEsc[mNotice:/Stage[main]/Foo::Home/File[/foo/x]/ensure:current_valueabsent,shouldbefile(noop)Esc[0m^{noformat}SomehowtheANSIcolorcode0;36hasdisappeared.Itshouldsay:{noformat}Esc[0;36mNotice:/Stage[main]/Foo::Home/File[/foo/x]/ensure:current_valueabsent,shouldbefile(noop)Esc[0m{noformat}(theendofalllines,Noticesincluded,arecorrectlyterminatedwithEsc[0m)
Add Comment
This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4387) Cyan colored notices
Title: Message Title
Elof Ofel updated an issue
Puppet / PUP-4387
Cyan colored notices
Change By:
Elof Ofel
Youseemtohavemadeatypoin(atleast)puppet3.7.4.Inpuppet2.7,running'puppetagent-t--noop'producedlotsofnotice-linesincyancolor.NowthatI'veupgradedto3.7.4,thecyancolorisgone.However,whenlookingattherawtextoutput,youseestrangeANSIcodes.Info-linesarecorrectlyformatted,butallNotice-linesareincorrect.Example: {noformat} Esc[0;32mInfo:LoadingfactsEsc[0mEsc[0;32mInfo:Cachingcatalogforfoo.bar.comEsc[0mEsc[0;32mInfo:Applyingconfigurationversion'1428593162'^[[0mEsc[mNotice:/Stage[main]/Foobarfiles::Home/File[/home/foo/.bashrc]/ensure:current_valueabsent,shouldbefile(noop)Esc[0m {noformat} SomehowtheANSIcolorcode0;36hasdisappeared.Itshouldsay: {noformat} Esc[0;36mNotice:/Stage[main]/Foobarfiles::Home/File[/home/foo/.bashrc]/ensure:current_valueabsent,shouldbefile(noop)Esc[0m {noformat} (theendofalllines,Noticesincluded,arecorrectlyterminatedwithEsc[0m)
Add Comment
This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4387) Cyan colored notices
Title: Message Title
Elof Ofel updated an issue
Puppet / PUP-4387
Cyan colored notices
Change By:
Elof Ofel
Youseemtohavemadeatypoin (atleast) puppet3.7. 4 x .Inpuppet2.7,running ' {{ puppetagent-t--noop ' }} producedlotsofnotice-linesincyancolor. Nowthat After I 've upgradedto3.7.4,thecyancolorisgone.However,whenlookingattherawtextoutput,youseestrangeANSIcodes.Info-linesarecorrectlyformatted,butallNotice-linesareincorrect.Example:{noformat}Esc[0;32mInfo:LoadingfactsEsc[0mEsc[0;32mInfo:Cachingcatalogforfoo.bar.comEsc[0mEsc[0;32mInfo:Applyingconfigurationversion'1428593162'Esc[0mEsc[mNotice:/Stage[main]/Foo::Home/File[/foo/x]/ensure:current_valueabsent,shouldbefile(noop)Esc[0m^{noformat}SomehowtheANSIcolorcode0;36hasdisappeared.Itshouldsay:{noformat}Esc[0;36mNotice:/Stage[main]/Foo::Home/File[/foo/x]/ensure:current_valueabsent,shouldbefile(noop)Esc[0m{noformat}(theendofalllines,Noticesincluded,arecorrectlyterminatedwithEsc[0m)
Add Comment
This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
