Jira (PDB-5257) Example code for PuppetDB query is not correct
Title: Message Title Henry Wang commented on PDB-5257 Re: Example code for PuppetDB query is not correct Hi, I see the doc is still wrong without update: https://puppet.com/docs/puppetdb/7/api/query/examples-pql.html#fact-report-status-filtering-with-dot-notation Please update the doc. Thank you. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.414481.1630996799000.134573.1632208080026%40Atlassian.JIRA.
Jira (PDB-5256) Puppet Query should have proper error message when it is failed
Title: Message Title Henry Wang updated an issue PuppetDB / PDB-5256 Puppet Query should have proper error message when it is failed Change By: Henry Wang Attachment: puppet-error.txt Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.414480.1630996076000.123879.1630996440035%40Atlassian.JIRA.
Jira (PDB-5256) Puppet Query should have proper error message when it is failed
Title: Message Title
Henry Wang created an issue
PuppetDB / PDB-5256
Puppet Query should have proper error message when it is failed
Issue Type:
Improvement
Assignee:
Unassigned
Created:
2021/09/06 11:27 PM
Environment:
PE 2021.2
Priority:
Normal
Reporter:
Henry Wang
When Puppet Query fails, for example, due to a syntax issue, it should give some error message like: "server encountered an error processing search request (more information might be found in puppetdb server’s log files)" Currently, the error message is misleading:
[root@pe-202100-master ~]# puppet query 'inventory[certname, facts.os.family, facts.puppetversion] { certname in nodes { latest_report_status = "failed" } }' --urls http://localhost:8080
2021/09/05 23:48:34 ERROR - &{ } (*models.ServerError) is not supported by the TextConsumer, can be resolved by supporting TextUnmarshaler interface
Jira (PDB-5162) Accept wildcard `*` for PDB API endpoints
Title: Message Title
Henry Wang updated an issue
PuppetDB / PDB-5162
Accept wildcard `*` for PDB API endpoints
Change By:
Henry Wang
We have a user case that the following API call is reported as working from PE 2019.2.1 (6.7.3) but stopped working after an upgrade to PE 2019.8.6 (6.16.1):{code:java} curl -G 'https://corp-puppet-db-np.homedepot.com:8081/pdb/query/v4/environments/*/reports' --data-urlencode 'query=["=", "noop", false]' --data-urlencode 'limit=1' {code}After the upgrade, the user just get "not found" returned from that query. Based on some simple troubleshooting, the query works fine if the user substitute one of our environments for '*'. I don't find any document saying `*` is supported in these PE versions. Thus, this ticket created as a feature request first to explorer as it sounds like a good feature to have. Any comments from PDB engineering team are appreciated.
Add Comment
This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)
--
You received this message because you
Jira (PDB-5162) Accept wildcard `*` for PDB API endpoints
Title: Message Title
Henry Wang updated an issue
PuppetDB / PDB-5162
Accept wildcard `*` for PDB API endpoints
Change By:
Henry Wang
We have a user use case that the following API call is reported as working from PE 2019.2.1 (6.7.3) but stopped working after an upgrade to PE 2019.8.6 (6.16.1):{code:java}curl -G 'https://corp-puppet-db-np.homedepot.com:8081/pdb/query/v4/environments/*/reports' --data-urlencode 'query=["=", "noop", false]' --data-urlencode 'limit=1' {code}After the upgrade, the user just get "not found" returned from that query. Based on some simple troubleshooting, the query works fine if the user substitute one of our environments for '*'. I don't find any document saying `*` is supported in these PE versions. Thus, this ticket created as a feature request first to explorer as it sounds like a good feature to have. Any comments from PDB engineering team are appreciated.
Add Comment
This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)
--
You received this message because you
Jira (PDB-5162) Accept wildcard `*` for PDB API endpoints
Title: Message Title Henry Wang updated an issue PuppetDB / PDB-5162 Accept wildcard `*` for PDB API endpoints Change By: Henry Wang Component/s: PuppetDB Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.403890.162390889.59087.1623909000231%40Atlassian.JIRA.
Jira (PDB-5162) Accept wildcard `*` for PDB API endpoints
Title: Message Title Henry Wang updated an issue PuppetDB / PDB-5162 Accept wildcard `*` for PDB API endpoints Change By: Henry Wang Affects Version/s: PDB 6.16.1 Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.403890.162390889.59086.1623909000179%40Atlassian.JIRA.
Jira (PDB-5162) Accept wildcard `*` for PDB API endpoints
Title: Message Title Henry Wang created an issue PuppetDB / PDB-5162 Accept wildcard `*` for PDB API endpoints Issue Type: New Feature Assignee: Unassigned Created: 2021/06/16 10:48 PM Priority: Normal Reporter: Henry Wang We have a user case that the following API call is reported as working from PE 2019.2.1 (6.7.3) but stopped working after an upgrade to PE 2019.8.6 (6.16.1): curl -G 'https://corp-puppet-db-np.homedepot.com:8081/pdb/query/v4/environments/*/reports' --data-urlencode 'query=["=", "noop", false]' --data-urlencode 'limit=1' After the upgrade, the user just get "not found" returned from that query. Based on some simple troubleshooting, the query works fine if the user substitute one of our environments for '*'. I don't find any document saying `*` is supported in these versions. Thus, this ticket created as a feature request first to explorer as it sounds like a good feature to have. Any comments from PDB engineering team are appreciated.
Jira (FACT-2992) Processors fact is good to include Sockets, Threads details
Title: Message Title Henry Wang created an issue Facter / FACT-2992 Processors fact is good to include Sockets, Threads details Issue Type: Improvement Assignee: Unassigned Created: 2021/03/21 9:53 PM Priority: Normal Reporter: Henry Wang The current processors fact only contains the following information: https://puppet.com/docs/puppet/7.5/core_facts.html#processors We have received user's feedbacks that it is good to include more details such as Thread(s) per core, Core(s) per socket. For example: lscpu | grep -e '^CPU(s)' -e '^Thread(s)' -e '^Core(s)' -e '^Socket(s)' CPU(s): 96 Thread(s) per core: 2 Core(s) per socket: 24 Socket(s): 2 Our processors fact only has the CPU count without Core(s) per socket and Thread(s) information:
Jira (PDB-5001) PuppetDB Cli pupept-query command not respecting https_proxy environment variable
Title: Message Title
Henry Wang updated an issue
PuppetDB / PDB-5001
PuppetDB Cli pupept-query command not respecting https_proxy environment variable
Change By:
Henry Wang
puppet-query doesn't respect environmental https_proxy settings like the other CLI commands. also we didn't find a way to configure it through CLI conf file. This will stop users who have to run this query behind a proxy. Way to reproduce: **{code:java} [root@puppetmom ~]# puppet-job show ID STATUS JOB TYPE TIMESTAMP TARGET - 537 finished puppet_agent::version 01/20/21 09:26:25 windowsagent.platform9.pupp... 536 finished puppet_agent::version 01/20/21 09:25:26 windowsagent.platform9.pupp... 535 finished puppet_agent::version 01/20/21 08:21:17 windowsagent.platform9.pupp...[root@puppetmom ~]# puppet-query "nodes[certname] { }" [ { "certname": "centosagentfor75.platform9.puppet.net" }, { "certname": " cm-lb01 cd4pemom75 .platform9.puppet.net"...{code}Once a dummy https_proxy is set, puppet-job will fail but puppet-query is not impacted:{code:java} [root@puppetmom ~]# export https_proxy=socks5h://localhost:12345[root@puppetmom ~]# puppet-job showRequest to 'https://puppetmom.platform9.puppet.net:8143/orchestrator/v1/jobs' failed: Couldn't connect to server[root@puppetmom ~]# puppet-query "nodes[certname] { }"[ {"certname": "centosagentfor75.platform9.puppet.net" }, {"certname": "puppetmom.platform9.puppet.net"{code}
Add Comment
Jira (PDB-5001) PuppetDB Cli pupept-query command not respecting https_proxy environment variable
Title: Message Title
Henry Wang created an issue
PuppetDB / PDB-5001
PuppetDB Cli pupept-query command not respecting https_proxy environment variable
Issue Type:
Bug
Assignee:
Unassigned
Created:
2021/01/20 11:25 PM
Priority:
Normal
Reporter:
Henry Wang
puppet-query doesn't respect environmental https_proxy settings like the other CLI commands. also we didn't find a way to configure it through CLI conf file. This will stop users who have to run this query behind a proxy. Way to reproduce:
[root@puppetmom ~]# puppet-job show ID STATUS JOB TYPE TIMESTAMP TARGET - 537 finished puppet_agent::version 01/20/21 09:26:25 windowsagent.platform9.pupp... 536 finished puppet_agent::version 01/20/21 09:25:26 windowsagent.platform9.pupp... 535 finished puppet_agent::version 01/20/21 08:21:17 windowsagent.platform9.pupp...
[root@puppetmom ~]# puppet-query "nodes[certname] { }" [ { "certname": "centosagentfor75.platform9.puppet.net" }, { "certname": "cm-lb01.platform9.puppet.net"
...
Jira (FACT-2918) FACTER_ environmental facts overrides don't work with external facts
Title: Message Title
Henry Wang updated an issue
Facter / FACT-2918
FACTER_ environmental facts overrides don't work with external facts
Change By:
Henry Wang
Overriding Using cli, overriding external facts from the cli works with facter but not in puppet.Reproducing steps:when the external fact things don't exist:{code:java} [root@goat01 facts.d]# pwd/etc/puppetlabs/facter/facts.d[root@goat01 facts.d]# ll things.txtls: cannot access things.txt: No such file or directory[root@goat01 facts.d]# facter -p things[root@goat01 facts.d]# FACTER_things=stuff facter -p thingsstuff[root@goat01 facts.d]# FACTER_things=stuff puppet facts|grep things"things": "stuff",[root@goat01 facts.d]# FACTER_things=stuff puppet apply -e 'notify{"things=>${facts.get(things)}<":}'Notice: Compiled catalog for goat01.unix.gsm1900.org in environment production in 0.02 secondsNotice: things=>stuffstuff<]/message: defined 'message' as 'things=>stuff<'Notice: Applied catalog in 0.06 seconds{code}however, when external facts exist. create external fact things with value 'NOT_STUFF':{code:java} [root@goat01 facts.d]# echo things=NOT_STUFF > things.txt[root@goat01 facts.d]# facter -p thingsNOT_STUFF[root@goat01 facts.d]# FACTER_things=stuff facter -p things #<-- worksstuff[root@goat01 facts.d]# FACTER_things=stuff puppet facts|grep things #<-- doesnt"things": "NOT_STUFF",[root@goat01 facts.d]# FACTER_things=stuff puppet apply -e 'notify{"things=>${facts.get(things)}<":}'Notice: Compiled catalog for goat01.unix.gsm1900.org in environment production in 0.02 secondsNotice: things=>NOT_STUFFNOT_STUFF<]/message: defined 'message' as 'things=>NOT_STUFF<'Notice: Applied catalog in 0.06 seconds {code}Conclusion: using cli, when external facts exist, environment facts FACTER_ will not overwrite the external facts in Puppet run. facter -p can display the overwritten value but puppet facts and puppet run can't.
Add Comment
Jira (FACT-2918) FACTER_ environmental facts overrides don't work with external facts
Title: Message Title Henry Wang created an issue Facter / FACT-2918 FACTER_ environmental facts overrides don't work with external facts Issue Type: Bug Assignee: Unassigned Created: 2021/01/13 11:27 PM Environment: PE 2019.8.4 Priority: Normal Reporter: Henry Wang Overriding external facts from the cli works with facter but not in puppet. Reproducing steps: when the external fact things don't exist: [root@goat01 facts.d]# pwd /etc/puppetlabs/facter/facts.d [root@goat01 facts.d]# ll things.txt ls: cannot access things.txt: No such file or directory [root@goat01 facts.d]# facter -p things
Jira (PUP-10585) Puppet::Util::Yaml safe_load not loading "Time" class which leads to compilation error for time serial data
Title: Message Title Henry Wang commented on PUP-10585 Re: Puppet::Util::Yaml safe_load not loading "Time" class which leads to compilation error for time serial data Josh Cooper Fantastic! yeah, I saw it, double confirm in 6.16.0, same persistence.rb: Error: Transaction store file /opt/puppetlabs/puppet/cache/state/transactionstore.yaml is corrupt ((/opt/puppetlabs/puppet/cache/state/transactionstore.yaml): Tried to load unspecified class: Time); replacing /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/yaml.rb:32:in `rescue in safe_load' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/yaml.rb:26:in `safe_load' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/yaml.rb:42:in `safe_load_file' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/persistence.rb:65:in `block in load' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:238:in `benchmark' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/persistence.rb:63:in `load' Glad team has decided to whitelist Time as well as Symbol classes.
Jira (PUP-10585) Puppet::Util::Yaml safe_load not loading "Time" class which leads to compilation error for time serial data
Title: Message Title Henry Wang updated an issue Puppet / PUP-10585 Puppet::Util::Yaml safe_load not loading "Time" class which leads to compilation error for time serial data Change By: Henry Wang Environment: Tested in PE 2019.8, but I think this should happen for:(1) any environment using safe_load(2) any classes not in the default list 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.366012.1594784795000.108008.1594784880111%40Atlassian.JIRA.
Jira (PUP-10585) Puppet::Util::Yaml safe_load not loading "Time" class which leads to compilation error for time serial data
Title: Message Title Henry Wang created an issue Puppet / PUP-10585 Puppet::Util::Yaml safe_load not loading "Time" class which leads to compilation error for time serial data Issue Type: Bug Assignee: Unassigned Created: 2020/07/14 8:46 PM Environment: PE 2019.8, but I think this should happen for: (1) any environment using safe_load (2) any classes not in the default list Priority: High Reporter: Henry Wang Puppet Version: 6.16.0 Puppet Server Version: PE 2019.8 OS Name/Version: RHEL Customer is using `audit -> mtime` in a file resource. When the time is saved into transactionstore.yaml. The next puppet agent run will fail with the following error: Error: Transaction store file /opt/puppetlabs/puppet/cache/state/transactionstore.yaml is corrupt ((/opt/puppetlabs/puppet/cache/state/transactionstore.yaml): Tried to load unspecified class: Time); replacing Wrapped exception: Tried to load unspecified class: Time This should be because Puppet::Util::Yaml is using
Jira (PUP-10352) Puppet agent total run time reported doesn't match time elapsed between Start and End event logs in Windows
Title: Message Title Henry Wang commented on PUP-10352 Re: Puppet agent total run time reported doesn't match time elapsed between Start and End event logs in Windows Right now we are asking Customer to enable debug mode and check if the above child is slow. 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.347072.158219188.39770.1586997120024%40Atlassian.JIRA.
Jira (PUP-10352) Puppet agent total run time reported doesn't match time elapsed between Start and End event logs in Windows
Title: Message Title Henry Wang commented on PUP-10352 Re: Puppet agent total run time reported doesn't match time elapsed between Start and End event logs in Windows Hi Mihai, Thanks for the tests. Unfortunately, the issue is reported not from my side but from the customer. But I indeed find something confusing me: I just checked my latest Puppet Interval Run for my Windows: 11:58:52 Applied catalog in 0.16 seconds 11:58:42 Executing agent with arguments It looks like the log time is matching the "0.16 seconds". From Puppet console, the metrics are: Run began:2020-04-15 23:58 Z Catalog submitted:2020-04-15 23:58 Z Run ended:2020-04-15 23:58 Z Report received:2020-04-15 23:58 Z Total runtime (sec):6.78 Config retrieval time (sec):0.72 Fact generation (sec):3.29 Transaction evaluation (sec):0.15
Jira (PUP-10352) Puppet agent total run time reported doesn't match time elapsed between Start and End event logs in Windows
Title: Message Title Henry Wang commented on PUP-10352 Re: Puppet agent total run time reported doesn't match time elapsed between Start and End event logs in Windows Hi team, here is the actual customer concern: Is it fair to say then that the timing of the manual puppet runs with 'puppet agent -t' and the puppet agent triggering its own 30 minute interval run should take about the same amount of time? That would be my expectation and they should roughly be doing the same activities in spite of how they are triggered - correct? May I know if this is the case, technically? At least from logging, the logs are different between the two for the Windows node. An interval run (1:25:32 - 1:26:43), 70s: 1:25:32 AM: "Executing agent with arguments:" 1:26:43 AM: "Applied catalog in 1.82 seconds" A bolt triggered manual run (10:07:52-10:08:20), less than 30 seconds: [10:07:52] rstuart@nix2 /home/rstuart: date ; bolt command run 'puppet agent -t' --targets pup-tst-w19-01 --password-prompt --user 'PLUTO\a-rstuart' Fri Feb 14 10:07:54 AEST 2020 Please enter your password: CLI arguments ["user",
Jira (FACT-2146) facter not returning expected ipaddress details on Solaris 10 with IPMP
Title: Message Title Henry Wang updated an issue Facter / FACT-2146 facter not returning expected ipaddress details on Solaris 10 with IPMP Change By: Henry Wang Attachment: ipmp-bug-data.txt Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.337174.1575268168000.50794.1575341280180%40Atlassian.JIRA.
Jira (FACT-2146) facter not returning expected ipaddress details on Solaris 10 with IPMP
Title: Message Title Henry Wang updated an issue Facter / FACT-2146 facter not returning expected ipaddress details on Solaris 10 with IPMP Change By: Henry Wang Attachment: s10_ipmp_facts_debug.zip Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.337174.1575268168000.48781.1575268800168%40Atlassian.JIRA.
Jira (FACT-2146) facter not returning expected ipaddress details on Solaris 10 with IPMP
Title: Message Title Henry Wang updated an issue Facter / FACT-2146 facter not returning expected ipaddress details on Solaris 10 with IPMP Change By: Henry Wang Attachment: s10_ipmp_facts_debug.zip Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.337174.1575268168000.48783.1575268800181%40Atlassian.JIRA.
Jira (FACT-2146) facter not returning expected ipaddress details on Solaris 10 with IPMP
Title: Message Title Henry Wang updated an issue Facter / FACT-2146 facter not returning expected ipaddress details on Solaris 10 with IPMP Change By: Henry Wang Comment: A comment with security level 'Developers' was removed. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.337174.1575268168000.48782.1575268800176%40Atlassian.JIRA.
Jira (FACT-2146) facter not returning expected ipaddress details on Solaris 10 with IPMP
Title: Message Title Henry Wang updated an issue Facter / FACT-2146 facter not returning expected ipaddress details on Solaris 10 with IPMP Change By: Henry Wang Attachment: s10_ipmp_facts_debug.zip Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.337174.1575268168000.48780.1575268740091%40Atlassian.JIRA.
Jira (FACT-2146) facter not returning expected ipaddress details on Solaris 10 with IPMP
Title: Message Title Henry Wang updated an issue Facter / FACT-2146 facter not returning expected ipaddress details on Solaris 10 with IPMP Change By: Henry Wang Attempting to configure IPMP on Solaris 10 results in networking structured fact returning 0.0.0.0 for primary ipaddressfrom glance at code, the ipaddress fact should not return 0.0.0.0 addresses on Solaris; however something is obviously not working as expected since as profile is updating /etc/hosts with this value (ie: 0.0.0.0 from facts[ipaddress])See attached output from ‘puppet facts –debug –evaltrace 2>&1’ both before and after a failover:usyddbp4200# puppet facts --debug --evaltrace > /tmp/before 2>&1usyddbp4200# if_mpadm -d vnet0usyddbp4200# puppet facts --debug --evaltrace > /tmp/after 2>&1usyddbp4200# if_mpadm -r vnet0(note: agent is Solaris 10_u11 however dropdown only has u1 as available option) Attachment: [^s10_ipmp_facts_debug.zip] Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received
Jira (FACT-2146) facter not returning expected ipaddress details on Solaris 10 with IPMP
Title: Message Title Henry Wang updated an issue Facter / FACT-2146 facter not returning expected ipaddress details on Solaris 10 with IPMP Change By: Henry Wang Attachment: s10_ipmp_facts_debug.zip Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.337174.1575268168000.48779.1575268680148%40Atlassian.JIRA.
Jira (FACT-2146) facter not returning expected ipaddress details on Solaris 10 with IPMP
Title: Message Title Henry Wang commented on FACT-2146 Re: facter not returning expected ipaddress details on Solaris 10 with IPMP Once IPMP is enabled in Solaris 10, once vnet0 is detached, it is still shown as `primary` nic with IP `0.0.0.0` and facter[ipaddress] will return that value instead of valid IP address binding to another nic. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.337174.1575268168000.48777.1575268380202%40Atlassian.JIRA.
Jira (FACT-2146) facter not returning expected ipaddress details on Solaris 10 with IPMP
Title: Message Title Henry Wang created an issue Facter / FACT-2146 facter not returning expected ipaddress details on Solaris 10 with IPMP Issue Type: Bug Assignee: Unassigned Attachments: s10_ipmp_facts_debug.zip Components: PE Created: 2019/12/01 10:29 PM Environment: PE: 2018.1.9, Solaris 10 Priority: Medium Reporter: Henry Wang Attempting to configure IPMP on Solaris 10 results in networking structured fact returning 0.0.0.0 for primary ipaddress from glance at code, the ipaddress fact should not return 0.0.0.0 addresses on Solaris; however something is obviously not working as expected since as profile is updating /etc/hosts with this value (ie: 0.0.0.0 from facts[ipaddress]) See attached output from ‘puppet facts –debug –evaltrace 2>&1’ both before and after a failover: usyddbp4200# puppet facts --debug --evaltrace > /tmp/before 2>&1 usyddbp4200# if_mpadm -d vnet0 usyddbp4200# puppet facts --debug --evaltrace > /tmp/after 2>&1 usyddbp4200# if_mpadm -r vnet0 (note: agent is Solaris 10_u11 however dropdown only has u1 as available option) Attachment: s10_ipmp_facts_debug.zip
Jira (PUP-10011) Tidy resource remove files even dependencies are failed
Title: Message Title Henry Wang commented on PUP-10011 Re: Tidy resource remove files even dependencies are failed The Tidy resource has shortcomings and likely not to be worked. Tidy resource in these examples can be replaced by an exec resource. As far as a technical reason, it is likely that the tidy resource does not pass the dependencies to the file resources that it generates. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.323802.1567763238000.103019.1568773380168%40Atlassian.JIRA.
Jira (PUP-10011) Tidy resource remove files even dependencies are failed
Title: Message Title
Henry Wang created an issue
Puppet / PUP-10011
Tidy resource remove files even dependencies are failed
Issue Type:
Task
Affects Versions:
PUP 6.4.3
Assignee:
Unassigned
Created:
2019/09/06 2:47 AM
Priority:
Normal
Reporter:
Henry Wang
Hi team, We got a problem regarding tidy resource. If we put a require => in tidy resource, for example require => Package['v'], if the package is failed to be absent, tidy will still remove files and then raise the Warning "Skipping because of failed depencies" For example, I write a simple Puppet code and tried to apply it: package { 'v': ensure => installed, } tidy { 'cleanup /tmp/tidytest': require => Package['v'], path => '/tmp/tidytest', age => '0', recurse => 1, rmdirs => false, matches => ['*'], } file { '/tmp/testfile.doc': ensure => present, require => Package['v'], } Due to package will not be installed. Then the result is /tmp/testfile.doc will not be created but all files under /tmp/tidytest will be removed. Both resources will raise the "Skipping because of failed depencies" but apparantly, tidy is triggered. Debug: Executing: '/bin/yum -d 0 -e 0 -y install v' Error: Execution of '/bin/yum -d 0 -e 0 -y install v' returned 1: Error: Nothing to do Error: /Stage[main]/Main/Package[v]/ensure: change from 'purged' to 'present' failed: Execution of '/bin/yum -d 0 -e 0 -y install v' returned 1: Error: Nothing to do Debug: /Stage[main]/Main/File[/tmp/tidytest/2]: Removing existing file for replacement with absent Notice: /Stage[main]/Main/File[/tmp/tidytest/2]/ensure: removed Debug: /Stage[main]/Main/File[/tmp/tidytest/2]: The container Class[Main] will propagate my refresh event Debug: /Stage[main]/Main/File[/tmp/tidytest/1]: Removing existing file for replacement with absent Notice: /Stage[main]/Main/File[/tmp/tidytest/1]/ensure: removed Debug: /Stage[main]/Main/File[/tmp/tidytest/1]: The container Class[Main] will propagate my refresh event Notice:
