Jira (PUP-11058) Detailed exitcode for 503s

2021-05-10 Thread Dylan Ratcliffe (Jira)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-11058  
 
 
  Detailed exitcode for 503s   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 2021/05/10 6:09 AM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 Puppet Version: All Puppet Server Version: All OS Name/Version: All When the Puppetserver is unavailable due to high load it will return a 503 error, which the agent handles gracefully by waiting for a specified period then running again. However when run manually with detailed exitcodes, there is no way to determine the difference between a 500 error due to failed catalog compilation and a 503 due to high load. Desired Behavior: A new exitcode is created for when the agent recieves a 503 from the server Actual Behavior: There is no specific exitcode   An example use case could be as part of a build process. You want the build to fail quickly if the Puppet run fails, but retry if there is too much load on the servers and detailed exit codes could be used for this.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
 

Jira (PDB-4172) Allow metrics during startup

2020-03-24 Thread Dylan Ratcliffe (Jira)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  PDB-4172  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Allow metrics during startup   
 

  
 
 
 
 

 
 I've not seen the impact of streaming provision so I can't really tell. The main issue was that PuppetDB on the secondary would sit there for hours with no metrics at all ad so you would have no way of really knowing what it was doing, how deep the queue was, how far it was from completing etc. If streaming sync (I'm not sure what that is) means that a 2 hour sync would be taken down to a few minutes that would be fine. If customers are still waiting 30min or so though it's good to have metrics.  
 

  
 
 
 
 

 
 
 

 
 
 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.282135.1540387252000.19035.1585041360035%40Atlassian.JIRA.


Jira (PUP-10292) external trusted data is executed for file_content requests

2020-02-12 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-10292  
 
 
  external trusted data is executed for file_content requests   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 PUP 6.12.0  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 2020/02/12 5:52 AM  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 Puppet Version: 6.12.0 Puppet Server Version: 6.8.0 OS Name/Version: RHEL When using the trusted_external_command setting, the command is executed for every file_content request, not just catalogs. This info can't possibly be required for a file_content request and this will cause a huge performance impact to the puppetserver as this could easily be executed 1000 times for a given node if it's new and needs to do a pluginsync, or if there are a lot of files managed. The error you see below is just from my trusted_external_command and is irrelevant other than show that it does execute it each time    
 
 
 
 
 172.17.0.2 - - - 12/Feb/2020:11:52:37 + "GET /puppet/v3/file_content/plugins/puppet/parser/functions/chomp.rb?environment=production& HTTP/1.1" 200 1295 172.17.0.2 172.17.0.2 8140 96  
 
 
 2020-02-12 11:52:37,545 WARN  [c.p.p.ShellUtils] Executed an external process which logged to STDERR: loading of puppet_x/external_data/multiplexer failed, no external data will be returned172.17.0.2 - - - 12/Feb/2020:11:52:37 + "GET /puppet/v3/file_content/plugins/puppet/parser/functions/chop.rb?environment=production& HTTP/1.1" 200 1343 172.17.0.2 172.17.0.2 8140 107  
   

Jira (PDB-2487) Allow for a "resource-events-ttl" to reduce the number of days of events that are stored

2019-10-03 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  PDB-2487  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Allow for a "resource-events-ttl" to reduce the number of days of events that are stored   
 

  
 
 
 
 

 
 Rob Browning Is there nothing we can do to get this moving faster? The ticket's been open for three years, there are at least 45 customers affected (the ones linked here) and it's pretty crippling for those that it does affect, plus it seems that the code is done. Though there is a workaround it's not normally a quick thing to diagnose and the implementation is pretty ugly. Plus if we were to be aggressive and set the ttl to say 2 days (since the console only ever uses one day for the event inspector) then we would likely mean that nobody ever needs to actually raise the ticket in the first place.  
 

  
 
 
 
 

 
 
 

 
 
 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.119255.1456852336000.128816.1570136641304%40Atlassian.JIRA.


Jira (BOLT-1478) Scripts without explicit interpreters don't work

2019-07-23 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-1478  
 
 
  Scripts without explicit interpreters don't work   
 

  
 
 
 
 

 
Change By: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 When running a task written in say; python, I would expect it to work if I have the python interpreter installed as normal on my system without specifying the interpreter as per the config docs: [https://puppet.com/docs/bolt/latest/bolt_configuration_options.html#sample-bolt-configuration-file]I have the following very basic task written in python:{code:java}  print("Goodbye, World!") {code}With the following metadata:{code:java}  {  "description": "does a python thing"} {code}When I run the task over PXP I get a 127 error as per PCP-879, but when I use bolt I get the following error:{code:java}  File extension .py is not enabled, to run it please add to 'winrm: extensions' {code}However the interpreters are set up correctly on the system as copying the file to the system and running the following command works:{code:java}  bolt command run "cmd.exe /c C:\ProgramData\PuppetLabs\pxp-agent\tasks-cache\e377cfba7d31e263cca6a946714b0e0904219892b95b72ebe60bd14e297e376b\init.py" --nodes winstudents -i inventory.yaml --debug {code} It appears that if the file doesn't have a known interpreter Bolt doesn't even try to execute it which surely is undesired behaviour.  Full debug output can be found in the "Environment" section  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

Jira (BOLT-1477) Inventory file v2 documentation should begin with an example

2019-07-22 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-1477  
 
 
  Inventory file v2 documentation should begin with an example   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 DOCS  
 
 
Created: 
 2019/07/22 4:55 AM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 The documentation for bolt inventory files v2 is written more as a "Here's what's different from v1" rather than a piece of documentation to be taken on its own. This makes it difficult to work out how the inventory file should be structured as you need to take both pieces of documentation and combine them in your head: v1: https://puppet.com/docs/bolt/latest/inventory_file.html v2: https://puppet.com/docs/bolt/latest/inventory_file_v2.html It would be better if the v2 has a full example at the beginning so that people could copy-paste-modify their way to victory instead of having to actually read the docs. Then they can read the sections the need if desired later, this is especially useful for readers who are coming back and already know what the settings do, but can't remember the exact format.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 


Jira (BOLT-1127) Bolt should echo port if custom SSH port is used

2019-07-10 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  BOLT-1127  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Bolt should echo port if custom SSH port is used   
 

  
 
 
 
 

 
 This would also be good for vagrant hosts which are much the same, all 127.0.0.1 with different ports  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.295971.1550016479000.10932.1562778900133%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


Jira (PUP-9786) Compiling catalog for AIX actually executes commands when managing users with group

2019-06-19 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  PUP-9786  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Compiling catalog for AIX actually executes commands when managing users with group   
 

  
 
 
 
 

 
 Ah that makes sense, workaround created: https://github.com/dylanratcliffe/onceover/pull/236  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.313097.156095524.53636.1560969900160%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


Jira (PUP-9786) Compiling catalog for AIX actually executes commands when managing users with group

2019-06-19 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9786  
 
 
  Compiling catalog for AIX actually executes commands when managing users with group   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 PUP 6.4.2  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 Types and Providers  
 
 
Created: 
 2019/06/19 7:40 AM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 Puppet Version: 6.4.2 Puppet Server Version: N/A OS Name/Version: AIX (any) When compiling a catalog for AIX, the user type causes the provider to actually execute commands using Puppet::Util::Execution.execute(). This is fine because they don't do anything and the catalog compiles fine anyway. However when we run tests on Windows with rspec-puppet, because it's pretending to be UNIX, the null_file is set to /dev/null https://github.com/puppetlabs/puppet/blob/3f7a06c50a8707811387dd60a6f7f26d94b606f4/lib/puppet/util/execution.rb#L191 and therefore ruby actually tries to read it, causing the catalog to fail with the following error:  
 
 
 
 
 No such file or directory @ rb_sysopen - /dev/null
  
 
 
 
  This essentially means that it's impossible to test code destined for AIX on Windows if it includes a user resource that is managing groups (It's group management that causes this) This can be 

Jira (PUP-9481) Setting certname in multiple sections bypasses validation

2019-02-08 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9481  
 
 
  Setting certname in multiple sections bypasses validation   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 PUP 6.0.5  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 2019/02/08 1:43 AM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 Puppet Version: 6.0.5 Puppet Server Version: N/A OS Name/Version: Windows Server 2012, CentOS 7 When a config file is created with the certname setting on both the agent and main sections as follows:  
 
 
 
 
 [main]  
 
 
 certname = my-windows-server.puppet.com  
 
 
 [agent]  
 
 
 certname = MY-WINDOWS-SERVER.puppet.com
  
 
 
 
  Puppet's validation that certnames must be lowercase if bypassed and allows for very broken certs to be generated Desired Behavior: Cert generation fails with "Error: Could not initialize global default 

Jira (PUP-9481) Setting certname in multiple sections bypasses validation

2019-02-08 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9481  
 
 
  Setting certname in multiple sections bypasses validation   
 

  
 
 
 
 

 
Change By: 
 Dylan Ratcliffe  
 
 
CS Priority: 
 Needs Priority  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (BOLT-459) Reboot a target and wait for it to become available.

2018-12-11 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  BOLT-459  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Reboot a target and wait for it to become available.   
 

  
 
 
 
 

 
 Michael Smith The version on the forge documents a plan called reboot::wait but then go on to give an example of the reboot plan. Is this a typo?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (BOLT-733) I want to return a JSON array not an object from a task

2018-11-08 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  BOLT-733  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: I want to return a JSON array not an object from a task   
 

  
 
 
 
 

 
 This is a bug I think. The official puppet resource task from the forge returns a JSON array also as this is the default behaviour of ruby's to_json. This means it doesn't get parsed properly and returns just "_output" instead of proper structured data  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (BOLT-459) Reboot a target and wait for it to become available.

2018-10-31 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  BOLT-459  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Reboot a target and wait for it to become available.   
 

  
 
 
 
 

 
 As the person who wrote all of this initially some key points from customers that drove the way I implemented it and I think should be maintained: 
 
Customers shouldn't have to handle the error that the reboot task generates. I guess you could just have a plan that does it, but the UX would however be much nicer if it is smart about the way it deliberately orphans a process so that PXP/Bolt can exit cleanly without cancelling the reboot (My ruby does this) 
Waiting for reboots needs configurable timeouts for the following: 
 
How long to wait for the machine to go down (If it doesn't go down we don't want to be waiting forever) 
How to long to then wait for the machine to come back up. Bear in mind for physical servers it's realistic that it might take an hour to reboot as all services need to be brought down cleanly 
Remember that it needs to wait for it to explicitly disconnect and reconnect. If the server takes 10min to shut down and all you are doing is waiting for it to be connected, it will return before the server has even shut down as it will be connected the first time you check 
  
  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 
   

Jira (PDB-4072) HA out-of-sync after restart

2018-10-24 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  PDB-4072  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: HA out-of-sync after restart   
 

  
 
 
 
 

 
 Done: PDB-4172  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (PDB-4172) Allow metrics during startup

2018-10-24 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 PuppetDB /  PDB-4172  
 
 
  Allow metrics during startup   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 2018/10/24 6:20 AM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 Large HA PuppetDB may take up to an hour (maybe longer) to start due to the initial sync. During this time the HTTP metrics are not available and it is difficult to determine what the sync is doing and if it is progressing as expected. These are metrics that I use personally and are probably some of the more useful are (Bear in mind this is what infludb is calling them, won't map exactly): 
 
global_processed (To work out commands per second) 
global_processing-time 
queue_depth 
jvm-metrics_heap-memory_committed 
jvm-metrics_heap-memory_used 
jvm-metrics_cpu-usage 
global_message-persistence-time 
PDBReadPool_pool_Usage 
PDBReadPool_pool_Wait 
PDBWritePool_pool_Usage 
PDBWritePool_pool_Wait 
 Having these working as soon as the process starts instead of once it gets to a "running" state would be great, ideally none of the metrics would depend on the fact that PuppetDB is "running" as opposed to "starting"  
 

  
 
 
 
 
  

Jira (PDB-4072) HA out-of-sync after restart

2018-10-23 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  PDB-4072  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: HA out-of-sync after restart   
 

  
 
 
 
 

 
 Yeah that's certainly possible. It would be good if the monitoring could come up while PuppetDB is in "starting" mode, that way we could get a lot more detail. Is there a technical reason why that doesn't happen? At the moment we get zero metrics until the PuppetDB is fully started which makes identifying these kinds of issues harder  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (PDB-4072) HA out-of-sync after restart

2018-10-23 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  PDB-4072  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: HA out-of-sync after restart   
 

  
 
 
 
 

 
 Austin Blatt just had to restart PuppetDB in order to increase report-ttl and we encountered this issue again. This time the primary was restarted and took about 40min to come back into sync due to being out by thousands of reports (~8000) and hundreds of everything else. I also saw the sync complete, PuppetDB come up fully, then it run sync again and say it needs to sync ~900 factsets, it syncs maybe 100-150 (judging by logs, very rough estimate) then stops, saying sync completed successfully. This repeats every 2min when sync is triggered about 5 or 6 times. In the meantime the secondary syncs a few thousand reports from the primary, which should have nothing that the secondary does not as the secondary was up the whole time.   Is this behaviour consistent with your hypothesis? Seems the initial huge sync is consistent, but I can't see why after the first sync completes, it would need to transfer anything further, especially 5 or 6 times, in both directions.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (PDB-4157) Review impact of connection limits in clj-http-client

2018-10-23 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 PuppetDB /  PDB-4157  
 
 
  Review impact of connection limits in clj-http-client   
 

  
 
 
 
 

 
Change By: 
 Dylan Ratcliffe  
 
 
CS Priority: 
 Needs Priority  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (PDB-4157) Review impact of connection limits in clj-http-client

2018-10-15 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 PuppetDB /  PDB-4157  
 
 
  Review impact of connection limits in clj-http-client   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 2018/10/15 8:52 PM  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 All teams that use clj-http-client should review the impact of the changes described in PE-25106. The clj-http-client previously defaulted to a maximum of 2 connection per route (host & port combination) and was not configurable. This led to many performance bottlenecks and is likely the root cause of many unsolved issues at large customers. Any code that uses this library should: 
 
Define a default that is appropriate for the use case 
Expose the values in config 
Make appropriate changes to the puppet_enterprise module to allow customers to make changes 
  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
  

Jira (PDB-4072) HA out-of-sync after restart

2018-10-15 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  PDB-4072  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: HA out-of-sync after restart   
 

  
 
 
 
 

 
 Austin Blatt no need for alternatives we can wait. The only impact is increased startup time when the Primary needs to restart PuppetDB for whatever reason. Workaround is just to not restart PuppetDB in the middle of the day, easy.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (BOLT-832) Orchestrator/PXP/PCP treats everything as text and subsequently fails with anything large

2018-10-09 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  BOLT-832  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Orchestrator/PXP/PCP treats everything as text and subsequently fails with anything large   
 

  
 
 
 
 

 
 Nick Lewis Using PE I have run the exec task with a parameter "base64 /dev/urandom | head -c {num bytes}" to generate large task responses and the limit I see is around "base64 /dev/urandom | head -c 120" (1.2Mb) much, much lower than the 64Mb that it is designed to handle. The failure mode in this scenario is orchestration-services crashes with no error and restarts. This is using a single monolithic master with one node. While this is clearly an issue as it's more than an order of magnitude lower than expected, this is not the main problem. The main problem is that even if 64Mb did work, it is vastly too low, many enterprise users have to deal with agents from large enterprise software vendors (who shall not be named) that are well into the hundreds of megabytes and installing these using a task is a valid use-case which we should handle. Users running Bolt over SSH or WinRM are used to being able to upload files of almost any size using entirely free software, moving to the paid version of Puppet Enterprise should not result in a reduction in functionality  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.

Jira (PDB-4072) HA out-of-sync after restart

2018-10-08 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  PDB-4072  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: HA out-of-sync after restart   
 

  
 
 
 
 

 
 Austin Blatt, attached to private Google Drive link. I have also attached logs from the primary after a reboot (whole server) that was required, might give some more info.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (BOLT-832) Orchestrator/PXP/PCP treats everything as text and subsequently fails with anything large

2018-10-03 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  BOLT-832  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Orchestrator/PXP/PCP treats everything as text and subsequently fails with anything large   
 

  
 
 
 
 

 
 I would disagree with this being minor, it's not a stretch to assume someone using PXP might want to use the file upload functionality to upload an 800Mb file, which would completely bring down orchestration as it's loaded into memory. Adam Bottchen can we please get a CS review of this?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (BOLT-838) Bolt debug output is not helpful

2018-10-03 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  BOLT-838  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Bolt debug output is not helpful   
 

  
 
 
 
 

 
 I don't know how that analytics works but if it's doing blocking requests to servers in the US that will add a few seconds each time as we have many hundreds of milliseconds of latency here  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (BOLT-838) Bolt debug output is not helpful

2018-10-03 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  BOLT-838  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Bolt debug output is not helpful   
 

  
 
 
 
 

 
 Real world use case: I just wasted 45min looking for why bolt's connections were timing out. Turns out the config file was in the wrong place and it was trying to connect to a PCP service-url from the client-tools config instead of bolt.yaml. I would have been able to work this out immediately if it gave me any indication of: 
 
Where config is being loaded from 
What URLs are being accessed and when 
  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (BOLT-838) Bolt debug output is not helpful

2018-09-14 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-838  
 
 
  Bolt debug output is not helpful   
 

  
 
 
 
 

 
Change By: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 The debug output for bolt is very noisy but doesn't say much about what bolt is actually doing, for example once a task completes bolt hangs for 2-3 seconds before exiting, what is it doing? There is no debug output at all, when using PCP we get a message when the orchestration client is created, but nothing about what request was submitted, what the response was, what follow-up requests are being submitted. Here is some example debug output with timestamps to show what could be improved:{code}[root@pe-201813-master ~]# bolt task run service --nodes pe-201813-master.puppetdebug.vlan --params @params.json --transport pcp --debug --configfile .puppetlabs/bolt.yaml 2>&1 | gawk '{ print strftime("[%H:%M:%S]"), $0 }'[06:08:36] Could not read inventory file: /root/.puppetlabs/inventory.yaml[06:08:36] Did not find config for pe-201813-master.puppetdebug.vlan in inventory[06:08:36] Submitting analytics: {[06:08:36]   "v": 1,[06:08:36]   "cid": "b8322956-1f52-4830-9a87-bb3367c4b213",[06:08:36]   "tid": "UA-120367942-1",[06:08:36]   "an": "bolt",[06:08:36]   "av": "0.21.8",[06:08:36]   "aip": true,[06:08:36]   "ul": "en-AU",[06:08:36]   "cd1": "CentOS 7",[06:08:36]   "t": "screenview",[06:08:36]   "cd": "task_run",[06:08:36]   "cd5": "human",[06:08:36]   "cd4": 1,[06:08:36]   "cd2": 0,[06:08:36]   "cd3": 1[06:08:36] }## What was it doing for these 5 seconds?[06:08:41] Completed analytics submission## And these 56 seconds?[06:09:37] ModuleLoader: module 'aggregate' has unknown dependencies - it will have all other modules visible[06:09:37] ModuleLoader: module 'canary' has unknown dependencies - it will have all other modules visible[06:09:37] ModuleLoader: module 'facts' has unknown dependencies - it will have all other modules visible[06:09:37] ModuleLoader: module 'puppetdb_fact' has unknown dependencies - it will have all other modules visible[06:09:37] Started with 10 max thread(s)[06:09:37] ModuleLoader: module 'boltlib' has unknown dependencies - it will have all other modules visible[06:09:37] Did not find config for pe-201813-master.puppetdebug.vlan in inventory[06:09:37] Starting: task service on pe-201813-master.puppetdebug.vlan[06:09:37] Submitting analytics: {[06:09:37]   "v": 1,[06:09:37]   "cid": "b8322956-1f52-4830-9a87-bb3367c4b213",[06:09:37]   "tid": "UA-120367942-1",[06:09:37]   "an": "bolt",[06:09:37]   "av": "0.21.8",[06:09:37]   "aip": true,[06:09:37]   "ul": "en-AU",[06:09:37]   "cd1": "CentOS 7",[06:09:37]   "t": "event",[06:09:37]   "ec": "Bundled Content",[06:09:37]   "ea": "Task",[06:09:37]   "el": "service"[06:09:37] }## Why do we need to submit analytics so often? And why do we need to print the whole hash?[06:09:37] Running task service with '{"action"=>"status", "name"=>"puppet", "_task"=>"service"}' via  on ["pe-201813-master.puppetdebug.vlan"][06:09:37] Creating orchestrator client for 

Jira (BOLT-839) Tasks should be able to have multi-segment names

2018-09-13 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-839  
 
 
  Tasks should be able to have multi-segment names   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 DOCS  
 
 
Created: 
 2018/09/13 9:06 PM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 Tasks follow the same naming convention as everything else in puppet with the exception that you can't use subfolders i.e. mymodule/tasks/subdfolder/foo.json will not result in a task named mymodule::subfolder::foo Ideally tasks should follow the same naming convention as everything else and allow folders, if not we need to update the docs to say something along the lines of: Only tasks in the root will be used, don't try to organise them, this won't work.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

Jira (BOLT-838) Bolt debug output is not helpful

2018-09-13 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-838  
 
 
  Bolt debug output is not helpful   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 CLI  
 
 
Created: 
 2018/09/13 8:06 PM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 The debug output for bolt is very noisy but doesn't say much about what bolt is actually doing, for example once a task completes bolt hangs for 2-3 seconds before exiting, what is it doing? There is no debug output at all, when using PCP we get a message when the orchestration client is created, but nothing about what request was submitted, what the response was, what follow-up requests are being submitted.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 

Jira (BOLT-837) Bolt fails to verify SSL certs using dns_alt_names

2018-09-13 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-837  
 
 
  Bolt fails to verify SSL certs using dns_alt_names   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 BOLT 0.22.0  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 CLI  
 
 
Created: 
 2018/09/13 6:42 PM  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 When running bolt against an orchestrator endpoint that uses whose name is in the dns_alt_names field of a cert, the certificate cannot be verified. Here is the Master's cert:  
 
 
 
 
 [root@pe-201813-master centos]# puppet cert print pe-201813-master.puppetdebug.vlan  
 
 
 Certificate:  
 
 
 Data:  
 
 
 Version: 3 (0x2)  
 
 
 

Jira (BOLT-832) Orchestrator/PXP/PCP treats everything as text and subsequently fails with anything large

2018-09-12 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-832  
 
 
  Orchestrator/PXP/PCP treats everything as text and subsequently fails with anything large   
 

  
 
 
 
 

 
Change By: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 *The Problem:*This is both a PCP/PXP/Orchestrator and bolt problem. When using bolt with pcp transport any tasks that involve sending even remotely large things to the client fail. e.g. using the {{run_script}} function on a script with greater than 65536 characters will cause an exception in the PXP broker and therefore bolt will return "Timed out waiting for provisional response". The {{upload_file}} function is even worse as that will POST an entire (possibly very large) file to the orchestrator API which will in turn try to store it in the database etc. Also any task that returns a large amount of data (>1MB) will cause issues. *Who will find it:*Any user using bolt with PXP will  likely  come across this.  It its  Users will  not  crazy  expect there  to  want to upload  be limitations when uploading  a 5Mb file or run a 1500 line script, both if which will cause orchestrator/PXP to fall over completely. Users will expect this to work as it works fine over SSH or WinRM  and it doesn't make sense that the PE transport has less capability .*Possible Solutions:*The PXP protocol needs to have streaming capabilities added so that it can transfer files in a similar way that users would expect to be able to over SSH. The Orchestrator API also will need to be modified to allow for binary data to be submitted or files uploaded, or something along those lines. Bolt will then need to be modified to take advantage of these features.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 

Jira (BOLT-832) Orchestrator/PXP/PCP treats everything as text and subsequently fails with anything large

2018-09-12 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-832  
 
 
  Orchestrator/PXP/PCP treats everything as text and subsequently fails with anything large   
 

  
 
 
 
 

 
Change By: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 *The Problem:*This is both a  PCP/  PXP /Orchestrator  and bolt problem. When using bolt with  PXP  pcp transport  any tasks that involve sending even remotely large things to the client fail. e.g. using the {{run_script}} function on a script with greater than 65536 characters will cause an exception in the PXP broker and therefore bolt will return "Timed out waiting for provisional response". The {{upload_file}} function is even worse as that will POST an entire (possibly very large) file to the orchestrator API which will in turn try to store it in the database etc. Also any task that returns a large amount of data (>1MB) will cause issues. *Who will find it:*Any user using bolt with PXP will come across this. It its not crazy to want to upload a 5Mb file or run a 1500 line script, both if which will cause orchestrator/PXP to fall over completely. Users will expect this to work as it works fine over SSH or WinRM and it doesn't make sense that the PE transport has less capability.*Possible Solutions:*The PXP protocol needs to have streaming capabilities added so that it can transfer files in a similar way that users would expect to be able to over SSH. The Orchestrator API also will need to be modified to allow for binary data to be submitted or files uploaded, or something along those lines. Bolt will then need to be modified to take advantage of these features.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

   

Jira (BOLT-832) Orchestrator/PXP/PCP treats everything as text and subsequently fails with anything large

2018-09-11 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-832  
 
 
  Orchestrator/PXP/PCP treats everything as text and subsequently fails with anything large   
 

  
 
 
 
 

 
Change By: 
 Dylan Ratcliffe  
 
 
Summary: 
 Orchestrator/PXP /PCP  treats everything as text and subsequently fails with anything large  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (BOLT-832) Orchestrator/PXP treats everything as text and subsequently fails with anything large

2018-09-11 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-832  
 
 
  Orchestrator/PXP treats everything as text and subsequently fails with anything large   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 BOLT 0.22.0  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 UX  
 
 
Created: 
 2018/09/11 10:22 PM  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 The Problem: This is both a PXP and bolt problem. When using bolt with PXP any tasks that involve sending even remotely large things to the client fail. e.g. using the run_script function on a script with greater than 65536 characters will cause an exception in the PXP broker and therefore bolt will return "Timed out waiting for provisional response". The upload_file function is even worse as that will POST an entire (possibly very large) file to the orchestrator API which will in turn try to store it in the database etc. Also any task that returns a large amount of data (>1MB) will cause issues.  Who will find it: Any user using bolt with PXP will come across this. It its not crazy to want to upload a 5Mb file or run a 1500 line script, both if which will cause orchestrator/PXP to fall over completely. Users will expect this to work as it works fine over SSH or WinRM and it doesn't make sense that the PE transport has less capability. Possible Solutions: The PXP protocol needs to have streaming capabilities added so that it can transfer files in a similar way that users would expect to be able to over SSH. The Orchestrator API also will need to be modified to allow for binary data to be submitted or files uploaded, or something along those lines. Bolt will then need to be modified to take advantage of these features.  
 

 

Jira (BOLT-820) bolt_shim module is not enough to effectively start with bolt

2018-09-11 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  BOLT-820  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: bolt_shim module is not enough to effectively start with bolt   
 

  
 
 
 
 

 
 I think the modules required is: {{mod 'puppetlabs-puppet_agent', '1.6.2' mod 'puppetlabs-bolt_shim', '0.1.1' mod 'puppetlabs-facts', '0.2.0' mod 'puppetlabs-service', '0.3.1' mod 'puppetlabs-package', '0.2.0' mod 'puppetlabs-puppet_conf', '0.2.0'}} But I would love some clarification form the bolt team.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (PDB-4072) HA out-of-sync after restart

2018-09-09 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 PuppetDB /  PDB-4072  
 
 
  HA out-of-sync after restart   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 PDB 5.2.4  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 HA  
 
 
Created: 
 2018/09/09 8:38 PM  
 
 
Environment: 
 PE 2018.1.3 HA with compile masters. The following things are out of the ordinary for this environment: 
 
~5500 Nodes 
Many hundreds of events per run (~250) 
Some resource titles over 4000 characters long 
  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 When running in a HA setup I'm seeing strange issues after restarting PuppetDB on either the Primary or Secondary master. Both masters will run fine for many hours/days with no sync errors. However after restart they will determine that they are are a long way out-of-sync and re-sync themselves, for example after both machines bing up for 4 days, restarting the primary caused it to re-sync 10,000 reports. This causes prolonged downtime as the PuppetDB service remains in "starting" mode and cannot process requests. Possibly there is some difference in the way that PuppetDB does an initial as opposed to one of the subsequent syncs?  
 

  
 
  

Jira (PDB-4072) HA out-of-sync after restart

2018-09-09 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 PuppetDB /  PDB-4072  
 
 
  HA out-of-sync after restart   
 

  
 
 
 
 

 
Change By: 
 Dylan Ratcliffe  
 
 
CS Priority: 
 Needs Priority  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (BOLT-820) bolt_shim module is not enough to effectively start with bolt

2018-08-29 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-820  
 
 
  bolt_shim module is not enough to effectively start with bolt   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 BOLT 0.21.8  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 DOCS, UX  
 
 
Created: 
 2018/08/29 6:01 PM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 When users follow the documentation to integrate bolt with PE, it tells them to install the bolt_shim module. This is however not enough to get Bolt working correctly. Almost all of the examples in the documentation won't work because they rely on more than just the tasks that come from that module. New users shouldn't have to understand all of this to get it working. Here's some suggestions for fixing this: 
 
Create dependencies on the bolt_shim module for all the other modules 
Document what other modules are required 
Both^? 
  
 

  
 
 
 
 

 
 
 

 
 

Jira (BOLT-796) Document how bundled content can be overridden

2018-08-29 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  BOLT-796  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Document how bundled content can be overridden   
 

  
 
 
 
 

 
 It's also important that this is not only documented but also standardised and released carefully as people using PXP will need to replicate the Bolt Puppetfile on their master. If it's undocumented it will be a pain but also if it changes drastically every release this will be painful  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (BOLT-818) Plans that don't return anything never get marked as complete in PE

2018-08-28 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-818  
 
 
  Plans that don't return anything never get marked as complete in PE   
 

  
 
 
 
 

 
Change By: 
 Dylan Ratcliffe  
 
 
Summary: 
 Plans that don' r t  return anything never get marked as complete in PE  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (BOLT-818) Plans that don'r return anything never get marked as complete in PE

2018-08-28 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-818  
 
 
  Plans that don'r return anything never get marked as complete in PE   
 

  
 
 
 
 

 
Change By: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 If I write a plan like below that just prints some stuff, it is never marked as complete in the PE GUI and is forever "In Progress"{code:puppet}plan test (  $server,) {  $targets = get_targets($server)  $target = $targets[0]  $result_set = run_task('facts::ruby', $target, '_catch_errors' => true)  $result_set.each |$result| {# Store facts for nodes from which they were succefully retrievedif ($result.ok) {  add_facts($result.target, $result.value)}  }  notice($targets)  notice($target)  notice($target.facts())}{code}If however I add a return value, it works fine:{code:puppet}plan test (  $server,) {  $targets = get_targets($server)  $target = $targets[0]  $result_set = run_task('facts::ruby', $target, '_catch_errors' => true)  $result_set.each |$result| {# Store facts for nodes from which they were succefully retrievedif ($result.ok) {  add_facts($result.target, $result.value)}  }  notice($targets)  notice($target)  notice($target.facts())  return false}{code}  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
  

Jira (BOLT-818) Plans that don

2018-08-28 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-818  
 
 
  Plans that don   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 2018/08/28 8:56 PM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at 

Jira (BOLT-818) Plans that don'r return anything never get marked as complete in PE

2018-08-28 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-818  
 
 
  Plans that don'r return anything never get marked as complete in PE   
 

  
 
 
 
 

 
Change By: 
 Dylan Ratcliffe  
 
 
Affects Version/s: 
 BOLT 0.21.8  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (BOLT-818) Plans that don'r return anything never get marked as complete in PE

2018-08-28 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-818  
 
 
  Plans that don'r return anything never get marked as complete in PE   
 

  
 
 
 
 

 
Change By: 
 Dylan Ratcliffe  
 
 
Summary: 
 Plans that don 'r return anything never get marked as complete in PE  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (FACT-1575) Add the ability to cache and block the output of custom facts

2018-08-12 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  FACT-1575  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Add the ability to cache and block the output of custom facts   
 

  
 
 
 
 

 
 Here's a workround until this is fully integrated, there were other modules on the forge before I wrote this but this has a less clunky API and is easier to integrate with existing custom facts: https://forge.puppet.com/dylanratcliffe/facter_cache  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (FACT-1380) Restore --timing option to native facter

2018-08-10 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  FACT-1380  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Restore --timing option to native facter   
 

  
 
 
 
 

 
 What information does this need? It would be super helpful to have this option back. To be clean this is not a Windows issue, it's just a feature that didn't survive the refactor to C (pun intended)  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (PUP-7163) regression - systemd provider does not honor documented enabled states

2018-07-08 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-7163  
 
 
  regression - systemd provider does not honor documented enabled states   
 

  
 
 
 
 

 
Change By: 
 Dylan Ratcliffe  
 
 
CS Priority: 
 Needs Priority  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (PDOC-237) @summary does not work

2018-04-16 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe commented on  PDOC-237  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: @summary does not work   
 

  
 
 
 
 

 
 Oh god, I'm an idiot. Thank you Henrik Lindberg  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (PDOC-178) @api private not showing up in generated docs

2018-04-16 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Strings /  PDOC-178  
 
 
  @api private not showing up in generated docs   
 

  
 
 
 
 

 
Change By: 
 Dylan Ratcliffe  
 
 
Affects Version/s: 
 PDOC 1.1.0  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (PDOC-237) @summary does not work

2018-04-16 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Strings /  PDOC-237  
 
 
  @summary does not work   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 2018/04/16 3:37 AM  
 
 
Environment: 
  
 
 
 
 
 > bundle show   
 
 
 Gems included by the bundle:  
 
 
   * addressable (2.5.2)  
 
 
   * ast (2.4.0)  
 
 
   * bundler (1.16.1)  
 
 
   * coderay (1.1.2)  
 
 
   * diff-lcs (1.3)  
 
 
   * docile (1.3.0)  
 
 
   * domain_name (0.5.20170404)  
 
 
   * facter (2.5.1)  
 
 

Jira (PUP-8434) Catalogs are not gzipped

2018-02-07 Thread Dylan Ratcliffe (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Ratcliffe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-8434  
 
 
  Catalogs are not gzipped   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 PUP 5.3.3  
 
 
Assignee: 
 Unassigned  
 
 
Attachments: 
 debug.txt  
 
 
Created: 
 2018/02/07 12:58 AM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 Dylan Ratcliffe  
 

  
 
 
 
 

 
 Puppet Version: 5.3.3 Puppet Server Version: 5.1.4 OS Name/Version: Centos 7 Puppetserver does not gzip catalogs, it should gzip everything. Desired Behavior: Everything is gzipped over the wire Actual Behavior: Everything but the catalog is gzipped over the wire Attached is the output of puppet agent -t --http_debug    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  

Jira (PUP-3329) Puppet agent can't clear a stale agent_catalog_run.lock file

2018-01-10 Thread Dylan Ratcliffe (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Dylan Ratcliffe commented on  PUP-3329 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Puppet agent can't clear a stale agent_catalog_run.lock file  
 
 
 
 
 
 
 
 
 
 
This should be fixed by 

PUP-7517
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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-1653) External Facts from PowerShell do not parse structured output (JSON/YAML)

2017-08-21 Thread Dylan Ratcliffe (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Dylan Ratcliffe commented on  FACT-1653 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: External Facts from PowerShell do not parse structured output (JSON/YAML)  
 
 
 
 
 
 
 
 
 
 
Workaround: Get a .bat file to call the .ps1 file 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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-1653) External Facts from PowerShell do not parse structured output (JSON/YAML)

2017-08-21 Thread Dylan Ratcliffe (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Dylan Ratcliffe commented on  FACT-1653 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: External Facts from PowerShell do not parse structured output (JSON/YAML)  
 
 
 
 
 
 
 
 
 
 
Also Bump? Also ran into this on-site with an enterprise customer today. We need this for building anything remotely useful (without wrapping it in ruby for no reason) in Windows (Current use case is listing pending updates) 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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 (PUP-6739) Error running puppet with non-existent and non-default environment

2017-06-08 Thread Dylan Ratcliffe (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Dylan Ratcliffe commented on  PUP-6739 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Error running puppet with non-existent and non-default environment  
 
 
 
 
 
 
 
 
 
 
It's worth noting here that this will also break puppetserver if you try to start puppetserver on a machine that doesn't have it's environment on disk. A good example of this is if you try to promote a non-production agent to a compile master, puppetserver fails to start because of this bug. Which is extra annoying because you need puppetserver running to get code manager/file-sync to actually create the directory and fix the issue. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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 (PUP-7628) Cannot run puppet commands or startup master when environment directory missing

2017-06-08 Thread Dylan Ratcliffe (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Dylan Ratcliffe commented on  PUP-7628 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Cannot run puppet commands or startup master when environment directory missing  
 
 
 
 
 
 
 
 
 
 
Thanks Josh Cooper I knew someone would be able to find it 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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 (PUP-7628) Cannot run puppet commands or startup master when environment directory missing

2017-06-07 Thread Dylan Ratcliffe (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Dylan Ratcliffe commented on  PUP-7628 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Cannot run puppet commands or startup master when environment directory missing  
 
 
 
 
 
 
 
 
 
 
Henrik Lindberg I figure you might know, was there a decision made on this behaviour in the past? Surely it has come up before 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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 (PUP-6513) Increase the amount of debug logging when using the lookup function

2017-04-04 Thread Dylan Ratcliffe (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Dylan Ratcliffe commented on  PUP-6513 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Increase the amount of debug logging when using the lookup function  
 
 
 
 
 
 
 
 
 
 
Henrik Lindberg Nicholas Fagerlund Please ignore me, had on old agent version that was running experimental lookup. v5 is excellent, well done  
 
 
 
 
 
 
 
 
 
 
 
 

 
 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 (PUP-6513) Increase the amount of debug logging when using the lookup function

2017-04-04 Thread Dylan Ratcliffe (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Dylan Ratcliffe commented on  PUP-6513 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Increase the amount of debug logging when using the lookup function  
 
 
 
 
 
 
 
 
 
 
Hey Henrik Lindberg Nicholas Fagerlund while this output is okay it would be good if we could get even more debug output, especially from the `puppet lookup` command. The use case being: 
"I have added a new layer to lookup that uses a value interpolated from a custom fact, but lookup is not finding any keys that I have defined at that new level" 
There could be a few things going on: 
 

yaml files have different capitalisation to the custom fact
 

syntax in hiera.yaml is wrong and the value is not being interpolated
 

The node does not have the custom fact and it is returning a blank value
 

You didn't realise that you needed to have ".yaml" at the end in the hierarchy
 
 
In these situations the above debug logging does not help, but the way hiera used to log was very helpful as it would tell you which file it was looking for at each level, so these situations were much easier to debug. It would be great if lookup did the same thing, logged which file it was looking for at each level so that we could debug error like the ones above. Should I be submitting a new ticket for this? 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed 

Jira (PDB-2862) PQL 'in' modifier doesn't work as advertised

2016-07-11 Thread Dylan Ratcliffe (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Dylan Ratcliffe created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 PuppetDB /  PDB-2862 
 
 
 
  PQL 'in' modifier doesn't work as advertised  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 PuppetDB 
 
 
 

Created:
 

 2016/07/10 11:24 PM 
 
 
 

Priority:
 
  Normal 
 
 
 

Reporter:
 
 Dylan Ratcliffe 
 
 
 
 
 
 
 
 
 
 
The following query works as expected: 
 
 
 
 
 
 
facts[] { value = "x86_64" }
 
 
 
 
 
 
 
Returning a bunch of data: 
 
 
 
 
 
 
[{"certname"=>"master.puppet.vm", 
 
 
 

Jira (PDB-2843) Exceptions when using functions

2016-06-26 Thread Dylan Ratcliffe (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Dylan Ratcliffe created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 PuppetDB /  PDB-2843 
 
 
 
  Exceptions when using functions  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 PuppetDB 
 
 
 

Created:
 

 2016/06/26 10:43 PM 
 
 
 

Priority:
 
  Normal 
 
 
 

Reporter:
 
 Dylan Ratcliffe 
 
 
 
 
 
 
 
 
 
 
When using any of the PQL functions it is very easy to get PuppetDB to throw a Input to munge-result-row does not match schema error. When this is thrown PuppetDB never responds to the query, causing it to timeout. 
All queries below are calling the root endpoint i.e. http://(master):8080/pdb/query/v4?query=(query) 
e.g. The following query: 
 
 
 
 
 
 
fact_contents[value] { path ~> ["memory",".*","available_bytes"] }
 
 
 
 
 
 
 
Returns the following data as expected:  
 
 
 
   

Jira (FACT-1398) selinux_config_policy should handle whitespace

2016-04-19 Thread Dylan Ratcliffe (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Dylan Ratcliffe created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Facter /  FACT-1398 
 
 
 
  selinux_config_policy should handle whitespace  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 FACT 3.1.5 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 2016/04/19 10:06 PM 
 
 
 

Priority:
 
  Normal 
 
 
 

Reporter:
 
 Dylan Ratcliffe 
 
 
 
 
 
 
 
 
 
 
Here we have a regex that is grabbing the selinux_config_policy from /etc/selinux/config. We had a customer here who had a space in their /etc/selinux/config which was breaking the regex as shown here 
This, and any other relevant regexes should be able to handle some whitespace at the end of the setting as it does not affect the functionality of SELinux at all. 
Suggested fix: Add whitespace to regex 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 

Jira (PUP-5857) custom_trusted_oid_mapping does not work

2016-02-09 Thread Dylan Ratcliffe (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Dylan Ratcliffe created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Puppet /  PUP-5857 
 
 
 
  custom_trusted_oid_mapping does not work  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 Puppet Server 
 
 
 

Created:
 

 2016/02/09 7:17 PM 
 
 
 

Priority:
 
  Normal 
 
 
 

Reporter:
 
 Dylan Ratcliffe 
 
 
 
 
 
 
 
 
 
 
Steps to reproduce: 
Create on master: 
 
 
 
 
 
 
/etc/puppetlabs/puppet/custom_trusted_oid_mapping.yaml 
 
 
 
 
 
 
--- 
 
 
 
 
oid_mapping: 
 
 
 
 

Jira (FACT-1292) Disk partition & mount point for Windows OS

2016-01-21 Thread Dylan Ratcliffe (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Dylan Ratcliffe commented on  FACT-1292 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Disk partition & mount point for Windows OS  
 
 
 
 
 
 
 
 
 
 
Joshuatly Tee In the meantime I have created a simple module, if you have customer that wants it urgently feel free to point them to it: https://forge.puppetlabs.com/dylanratcliffe/disk_facts 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
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.