Jira (PUP-1375) Kylo Test Sub-task

2014-01-04 Thread Kylo Ginsberg (JIRA) 
Title: Message Title










 

 Kylo Ginsberg created an issue











 






 Puppet /  PUP-1375



  Kylo Test Sub-task 










Issue Type:

  Sub-task




Assignee:

 Kylo Ginsberg




Created:


 03/Jan/14 11:59 PM




Priority:

  Normal




Reporter:

 Kylo Ginsberg










Kylo Test Sub-task Description












   

 Add Comment











 










 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














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

Jira (PUP-1374) Kylo Test Issue

2014-01-04 Thread Kylo Ginsberg (JIRA) 
Title: Message Title










 

 Kylo Ginsberg created an issue











 






 Puppet /  PUP-1374



  Kylo Test Issue 










Issue Type:

  Task




Assignee:


 Unassigned




Created:


 03/Jan/14 11:59 PM




Priority:

  Normal




Reporter:

 Kylo Ginsberg










Kylo Test Issue Description












   

 Add Comment











 










 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop rec

Jira (PUP-1373) Kylo Test Sub-task

2014-01-04 Thread Kylo Ginsberg (JIRA) 
Title: Message Title










 

 Kylo Ginsberg created an issue











 






 Puppet /  PUP-1373



  Kylo Test Sub-task 










Issue Type:

  Sub-task




Assignee:

 Kylo Ginsberg




Created:


 03/Jan/14 11:58 PM




Priority:

  Normal




Reporter:

 Kylo Ginsberg










Kylo Test Sub-task Description












   

 Add Comment











 










 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














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

Jira (PUP-1372) Kylo Test Issue

2014-01-04 Thread Kylo Ginsberg (JIRA) 
Title: Message Title










 

 Kylo Ginsberg created an issue











 






 Puppet /  PUP-1372



  Kylo Test Issue 










Issue Type:

  Task




Assignee:


 Unassigned




Created:


 03/Jan/14 11:58 PM




Priority:

  Normal




Reporter:

 Kylo Ginsberg










Kylo Test Issue Description












   

 Add Comment











 










 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop rec

Jira (PUP-1368) WIndows Scheduled Task causes seg-fault

2014-01-04 Thread Geek Man (JIRA) 
Title: Message Title










 

 Geek Man created an issue











 






 Puppet /  PUP-1368



  WIndows Scheduled Task causes seg-fault 










Issue Type:

  Bug




Affects Versions:


 3.4.1, 3.3.1




Assignee:


 Unassigned




Attachments:


 puppet-segfault-output-stderr.txt, puppet-test-manifest.txt




Components:


 Types and Providers




Created:


 04/Jan/14 1:06 AM




Environment:


Windows 2008 R2 64-bit, Windows 2008 R2 SP1 64-bit One agent with Puppet 3.3.1 and another with 3.4.1




Labels:


 windows




Priority:

  Major




Reporter:

 Geek Man

Jira (PUP-1368) WIndows Scheduled Task causes seg-fault

2014-01-04 Thread Geek Man (JIRA) 
Title: Message Title










 

 Geek Man updated an issue











 






 Puppet /  PUP-1368



  WIndows Scheduled Task causes seg-fault 










Change By:

 Geek Man









 In the past day I've implemented some scheduled tasks which invoke an MSSQL stored procedure via SQLCMD. Today I've found that these scheduled tasks are causing a segfault on any agent which they run.In almost all tests, I've been able to run the agent via "puppet agent --test --debug --trace". The first run will correctly create the scheduled task; but the second run will produce a segfault  of the puppet agent, causing the catalog run to never finish . Sometimes a third run was needed to get a segfault.The affected nodes so far are both Windows 2008 R2, but running different sets of updates (eg one is not SP1). Both were originally running Puppet 3.3.1, but I upgraded one of them to 3.4.1, which no effect.I've created a new 'test' module to simplify reproducing the bug. To test this bug I am simply adding "include test" to the node definition for chosen nodes.I've included the test module manifest for reproduction, as well as the stack strace I get when the segfault occurs.












   

 Add Comment











 










 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














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

Jira (PDB-106) Report processor in puppetdb-terminus fails if report has no metrics

2014-01-04 Thread Jason Antman (JIRA) 
Title: Message Title










 

 Jason Antman updated an issue











 






 PuppetDB /  PDB-106



  Report processor in puppetdb-terminus fails if report has no metrics 










Change By:

 Jason Antman




Summary:

 Report processor in puppetdb-terminus fails  during catalogue compilation failures  if report has no metrics












   

 Add Comment











 










 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














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

Jira (PDB-106) Report processor in puppetdb-terminus fails if report has no metrics

2014-01-04 Thread Jason Antman (JIRA) 
Title: Message Title










 

 Jason Antman updated an issue











 






 PuppetDB /  PDB-106



  Report processor in puppetdb-terminus fails if report has no metrics 










Change By:

 Jason Antman




Attachment:

 mco_traceback.txt












   

 Add Comment











 










 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














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

Jira (PDB-106) Report processor in puppetdb-terminus fails if report has no metrics

2014-01-04 Thread Jason Antman (JIRA) 
Title: Message Title










 

 Jason Antman commented on an issue











 






  Re: Report processor in puppetdb-terminus fails if report has no metrics 










I updated the Issue summary to reflect what seems to be the root cause... if a puppet run terminates early (or does not have a valid catalog), the report sent back has an empty metrics hash (i.e. "- metrics: {}"). The current report processor dies on this.
Relevant portion of the traceback: Error: Report processor failed: undefined method `[]' for nil:NilClass /usr/lib/ruby/site_ruby/1.8/puppet/reports/puppetdb.rb:81:in `run_duration' /usr/lib/ruby/site_ruby/1.8/puppet/reports/puppetdb.rb:50:in `report_to_hash' /usr/lib/ruby/site_ruby/1.8/puppet/reports/puppetdb.rb:19:in `process'
Code in question: def run_duration


long comment here metrics["time"]["total"] end


Seems to me like we should be checking whether that value exists or not, and if not, ignoring it (or returning some special value?)












   

 Add Comment











 













 PuppetDB /  PDB-106



  Report processor in puppetdb-terminus fails if report has no metrics 







 Sample content:   {code}  node "puppetdb1.vm" {    somesyntaxerror  }  {code}   When the report submitter tries to submit such a report, we get:   {{Feb 18 19:15:31 puppetdb1 puppet-master[28878]: Report processor failed: undefined method `[]' for nil:NilClass}}   On the puppetmaster ...

Jira (PUP-1320) service puppet ensure stopped kills off cron-run puppet with "Caught TERM; calling stop"

2014-01-04 Thread Jason Antman (JIRA) 
Title: Message Title










 

 Jason Antman commented on an issue











 






  Re: service puppet ensure stopped kills off cron-run puppet with "Caught TERM; calling stop" 










I got bitten by this one as well. It seems to me that "ensure => stopped" should be invalid (i.e. a runtime error) if the service name == the currently running puppet service.
I switched from daemon mode to running agents via a cron'ed "mco puppet runall" on the master, and setup a class identical to the reporter's: service  { 'puppet': ensure => stopped, enable => false }
and took about 6 hours digging into the problem, which only manifested itself as a failed puppetdb report processor (PDB-106). This seems to be happening because, when puppet applies that resource and kills itself ("Caught TERM; calling stop") it sends a report with an empty metrics hash, which causes an uncaught error in the puppetdb report handler.
This seems like a horrible shoot-yourself-in-the-foot case which simply shouldn't be allowed.












   

 Add Comment











 













 Puppet /  PUP-1320



  service puppet ensure stopped kills off cron-run puppet with "Caught TERM; calling stop" 







 We have recently switched from puppet agent in daemon mode (for kick) to cron-run puppet with mcollective agent. However, I started noticing that puppet policies were being inconsistently applied across the hosts. It turns out that this policy is the problem: service { 'puppet':  ensure => stopped,  enable => false,    ...















 This message was

Jira (PDB-106) Report processor in puppetdb-terminus fails if report has no metrics

2014-01-04 Thread Jason Antman (JIRA) 
Title: Message Title










 

 Jason Antman commented on an issue











 






  Re: Report processor in puppetdb-terminus fails if report has no metrics 










Confirmed that the Report Format 4 specification clearly says "Failed reports contain no metrics."
so... the report processor just errors out for any failed report...












   

 Add Comment











 













 PuppetDB /  PDB-106



  Report processor in puppetdb-terminus fails if report has no metrics 







 Sample content:   {code}  node "puppetdb1.vm" {    somesyntaxerror  }  {code}   When the report submitter tries to submit such a report, we get:   {{Feb 18 19:15:31 puppetdb1 puppet-master[28878]: Report processor failed: undefined method `[]' for nil:NilClass}}   On the puppetmaster ...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














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

Jira (PDB-106) Report processor in puppetdb-terminus fails on failed reports / reports with no metrics

2014-01-04 Thread Jason Antman (JIRA) 
Title: Message Title










 

 Jason Antman updated an issue











 






 PuppetDB /  PDB-106



  Report processor in puppetdb-terminus fails on failed reports / reports with no metrics 










Change By:

 Jason Antman




Summary:

 Report processor in puppetdb-terminus fails  if report has  on failed reports / reports with  no metrics












   

 Add Comment











 










 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














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

Jira (PDB-36) Add agent run failure information to reports

2014-01-04 Thread Jason Antman (JIRA) 
Title: Message Title










 

 Jason Antman commented on an issue











 






  Re: Add agent run failure information to reports 










This would be really cool. But at the moment, PDB-106, it's pointless because the report processor fails on failed reports.












   

 Add Comment











 













 PuppetDB /  PDB-36



  Add agent run failure information to reports 







 When a run fails due to catalog compilation, timeout, etc. there should be information regarding this in the reports.















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














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

Jira (PUP-1144) No longer allows variables with leading underscores

2014-01-04 Thread Kylo Ginsberg (JIRA) 
Title: Message Title










 

 Kylo Ginsberg commented on an issue











 






  Re: No longer allows variables with leading underscores 










I just did functional review of this on stable. Henrik Lindberg thanks for providing a snippet to reproduce - makes FR easy :>












   

 Add Comment











 













 Puppet /  PUP-1144



  No longer allows variables with leading underscores 







 It appears that puppet 3.4 has changed the rules for allowed variable names. A variable with a leading underscore (e.g. {{$_last}}), now results in an error.   https://github.com/puppetlabs/puppetlabs-apache/pull/540















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














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

Jira (PDB-106) Report processor in puppetdb-terminus fails on failed reports / reports with no metrics

2014-01-04 Thread Jason Antman (JIRA) 
Title: Message Title










 

 Jason Antman commented on an issue











 






  Re: Report processor in puppetdb-terminus fails on failed reports / reports with no metrics 










Pull request to fix this: https://github.com/puppetlabs/puppetdb/pull/785












   

 Add Comment











 













 PuppetDB /  PDB-106



  Report processor in puppetdb-terminus fails on failed reports / reports with no metrics 







 Sample content:   {code}  node "puppetdb1.vm" {    somesyntaxerror  }  {code}   When the report submitter tries to submit such a report, we get:   {{Feb 18 19:15:31 puppetdb1 puppet-master[28878]: Report processor failed: undefined method `[]' for nil:NilClass}}   On the puppetmaster ...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














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

Jira (PDB-106) Report processor in puppetdb-terminus fails on failed reports / reports with no metrics

2014-01-04 Thread Jason Antman (JIRA) 
Title: Message Title










 

 Jason Antman assigned an issue to Jason Antman











 






 PuppetDB /  PDB-106



  Report processor in puppetdb-terminus fails on failed reports / reports with no metrics 










Change By:

 Jason Antman




Assignee:

 Jason Antman












   

 Add Comment











 










 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














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

Jira (PUP-1369) Package options property for package

2014-01-04 Thread Jason Antman (JIRA) 
Title: Message Title










 

 Jason Antman updated an issue











 






 Puppet /  PUP-1369



  Package options property for package 










https://github.com/puppetlabs/puppet/pull/2034










Change By:

 Jason Antman




Component/s:

 Types and Providers












   

 Add Comment











 










 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














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

Jira (PUP-1369) Package options property for package

2014-01-04 Thread redmine.exporter (JIRA) 
Title: Message Title










 

 redmine.exporter created an issue











 






 Puppet /  PUP-1369



  Package options property for package 










Issue Type:

  New Feature




Assignee:


 Unassigned




Created:


 04/Jan/14 8:44 AM




Labels:


 redmine




Priority:

  Normal




Reporter:

 redmine.exporter










Hi,
Last few months I was trying to adapt the puppetlabs-apache module to work on FreeBSD (with some success). The rule is that puppetlabs-apache installs apache package internally as well as all the necessary packages that provide apache modules and additional features. The puppetlabs-apache decides what packages to install depending on configuration parameters defined in manifests (selection of MPM, additional modules and so on). On most platforms apache modules are available as small installable packages, so the extra modules are installed as separate packages - easy to do with puppet. This is not the case for FreeBSD. With FreeBSD ports we need to enable/disable certain "port options" on bigger packages (apache22, for example) in order to have given modules installed. Normally it's done at port configuration step (make config - ncurses GUI), after which the package is being compiled and installed. In a situation such as with puppetlabs-apache however, this should be done entirely by puppet class without additional user intervention.
What I would propose here is to add `package_options` property to `package` type in order to handle port options on FreeBSD. What may be put into this property should be provider-specific, so all the stuff such as validation, munging, syncing, etc. would be delegated to particular provider. The package_options could also be used by other providers, that have concepts similar to port opti

Jira (PDB-202) reports: Add a successful key with true/false

2014-01-04 Thread Jason Antman (JIRA) 
Title: Message Title










 

 Jason Antman commented on an issue











 






  Re: reports: Add a successful key with true/false 










This seems to effectively duplicate the request in PDB-36












   

 Add Comment











 













 PuppetDB /  PDB-202



  reports: Add a successful key with true/false 







 If you want to figure out if a run a node reported was successful you need to query for the reports of a node and using the returned hash of the run you're looking for query the events endpoint with a query of ["=", "report", "hash"].   Once that is done, walk through all the events returned and if an event's status is failed then the run should be consi...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














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

Jira (PDB-36) Add agent run failure information to reports

2014-01-04 Thread Daniele Sluijters (JIRA) 
Title: Message Title










 

 Daniele Sluijters commented on an issue











 






  Re: Add agent run failure information to reports 










As far as I and my request in PDB-202 are concerned, I don't necessarily need/want a boolean flag, but something.












   

 Add Comment











 













 PuppetDB /  PDB-36



  Add agent run failure information to reports 







 When a run fails due to catalog compilation, timeout, etc. there should be information regarding this in the reports.















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














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

Jira (PDB-16) Store status for reports

2014-01-04 Thread Jason Antman (JIRA) 
Title: Message Title










 

 Jason Antman commented on an issue











 






  Re: Store status for reports 










Wondering if there's an update on this?
1) Yes, the current report format only provides a "status" property (failed, changed, unchanged) that can determine the overall status, but nothing to determine a failure cause. However, PUP-283 and PUP-916 would fix that. Perhaps a spec for this "failure cause" data, to be included in a future Report Format 5, could be developed, implemented on the PDB side, and simply be empty until reports including it come in?
2) I understand that this is a PE customer ticket (I'm a PE customer as well), but there are a lot of us who would like to see this implemented ASAP in the OSS version... Not being able to tell whether a run was an overall failure or not is a serious gap in PuppetDB's usefulness.












   

 Add Comment











 













 PuppetDB /  PDB-16



  Store status for reports 







 We recently learned that when a puppet run fails due to catalog compilation error or catalog timeout, the agent will submit a report with a status of `failed`, but without any events.  Because the current implementation of report storage in PuppetDB relies entirely on events to indicate success/failure, there is no way to look at the PuppetDB data and det...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)

Jira (PUP-1370) when init scripts have been ported to upstart puppet does not detect service that are not working

2014-01-04 Thread redmine.exporter (JIRA) 
Title: Message Title










 

 redmine.exporter created an issue











 






 Puppet /  PUP-1370



  when init scripts have been ported to upstart puppet does not detect service that are not working 










Issue Type:

  Bug




Assignee:


 Unassigned




Created:


 04/Jan/14 11:22 AM




Labels:


 redmine




Priority:

  Normal




Reporter:

 redmine.exporter










I do not believe that this is a regresson and it was observed on 2.7.12
when a init script has been disabled, the following message is printed to stdout:
 root@db:~# /etc/init.d/mysql status Rather than invoking init scripts through /etc/init.d, use the service(8) utility, e.g. service mysql status
Since the script you are attempting to invoke has been converted to an Upstart job, you may also use the status(8) utility, e.g. status mysql mysql start/running, process 2765 root@db:~# echo $? 0 
unfortunately, it also has an exit code of 0 (related to #12773)
This means that puppet service does not detect that the script is not running:



service mysql stop


puppet resource service mysql warning: Service udev-fallback-graphics found in both debian and init; skipping the init version warning: Service dns-clean found in both debian and init; skipping the init version warning: Service vboxadd-x11 found in both d

Jira (PUP-1371) puppet cannot manage agent or master after update to puppet 3.2

2014-01-04 Thread redmine.exporter (JIRA) 
Title: Message Title










 

 redmine.exporter created an issue











 






 Puppet /  PUP-1371



  puppet cannot manage agent or master after update to puppet 3.2 










Issue Type:

  Bug




Assignee:


 Unassigned




Created:


 04/Jan/14 12:45 PM




Labels:


 redmine




Priority:

  Normal




Reporter:

 redmine.exporter










When puppet is configured to manage it's own services it fails, due to broken init scripts for EL6
 Notice: /Stage[main]/Puppet::Server/Service[puppetmaster]/ensure: ensure changed 'stopped' to 'running' Info: /Stage[main]/Puppet::Server/Service[puppetmaster]: Unscheduling refresh on Service[puppetmaster] Notice: /Stage[main]/Puppet/Service[puppet]/ensure: ensure changed 'stopped' to 'running' Info: /Stage[main]/Puppet/Service[puppet]: Unscheduling refresh on Service[puppet]


service puppetmaster status puppet dead but subsys locked


service puppet status puppet dead but subsys locked


ps auwx |grep puppet puppet 10167 0.3 5.6 207052 109260 ? Ssl 17:52 0:32 /usr/bin/ruby /usr/bin/puppet master root 13385 0.0 3.0 148236 59508 ? Ss 19:37 0:00 /usr/bin/ruby /usr/bin/puppet agent root 15789 0.0 0.0 103236 832 pts/0 S+ 20:08 0:00 grep puppet 


Looking into the configuration, I fo

Jira (PUP-1320) service puppet ensure stopped kills off cron-run puppet with "Caught TERM; calling stop"

2014-01-04 Thread Jason Antman (JIRA) 
Title: Message Title










 

 Jason Antman commented on an issue











 






  Re: service puppet ensure stopped kills off cron-run puppet with "Caught TERM; calling stop" 










This seems like a real conundrum to me (granted, I'm not positive, but it's possible this may be easier on newer RedHat versions that don't use SysV init).
On RedHat and derivatives, the Service type uses the "redhat" provider, and the "ext/redhat/client.init" script. When puppet is started with args like "--one-time --no-daemonize" it still writes out a PID file, by default to the same location (/var/run/puppet/agent.pid) that the init script uses. When we do "ensure => stopped" the provider calls the init script's status command, which dutifully checks the pid file, sees that the "/usr/bin/puppet" process with that PID is running (the puppet agent process that's applying the catalog, not necessarily any correlation to a daemon process that may or may not have been started via the init script), and kills it (effectively kills itself).
There's only a few things that I can think of, and none of them are pretty:


Use a different PID file for daemons started by the init script. Unfortunately this means the init script would be overriding the puppet.conf "pidfile" setting. This is probably bad for a number of reasons - it's confusing, it probably violates spec, and it makes it much more likely that there would be 2 instances of puppet running (possibly both daemons) if one was started via the init script and one manually.


Do something special in puppet, where if it's managing the "puppet" (or some way of figuring out what the right name is on different platforms) service, it defers any change of service status until the run is completed (which doesn't seem feasible because we couldn't reliably report on that event).


Write a "puppet" provider for the service type that passes everything but "ensure" on to the correct provider for the platform, and somehow wraps ensure in enough logic to not kill itself.


Add some sort of magic to the init script that doesn't kill a puppet process that's currently applying a catalog (it would be nice if we could pass the current PID to the script as an environment variable, but `service` doesn't work that way), possibly by looking for "applying configuration" in the process name, and not killing that. But this opens up a possible race condition.














   

 Add Comment

Jira (PUP-1320) service puppet ensure stopped kills off cron-run puppet with "Caught TERM; calling stop"

2014-01-04 Thread Jo Rhett (JIRA) 
Title: Message Title










 

 Jo Rhett commented on an issue











 






  Re: service puppet ensure stopped kills off cron-run puppet with "Caught TERM; calling stop" 










I disagree with Jason Antman. If you want to ensure the puppet daemon isn't running, disallowing puppet to check for the status means you need to install cfengine or salt to do this work for you. That's not sensible.
I don't believe it would be difficult for puppet to determine if the puppet daemon was running and stop it, without affecting puppet onetime processes started from cron or mcollective.












   

 Add Comment











 













 Puppet /  PUP-1320



  service puppet ensure stopped kills off cron-run puppet with "Caught TERM; calling stop" 







 We have recently switched from puppet agent in daemon mode (for kick) to cron-run puppet with mcollective agent. However, I started noticing that puppet policies were being inconsistently applied across the hosts. It turns out that this policy is the problem: service { 'puppet':  ensure => stopped,  enable => false,    ...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
You received this message because you are subscribed to

Jira (PUP-671) PR (2034): (#23084) Package options property for package - ptomulik

2014-01-04 Thread gepetto-bot (JIRA) 
Title: Message Title










 

 gepetto-bot commented on an issue











 






  Re: PR (2034): (#23084) Package options property for package - ptomulik 










jantman commented:
Agree with @adrienthebo about the naming - "build options" seems like a bad name for many other providers, where these options can't affect a build (i.e. the many package management systems that only install pre-built/compiled packages). I don't know if there's a name collision, but I'd also suggest extra_options as a possibility. 












   

 Add Comment











 













 Puppet /  PUP-671



  PR (2034): (#23084) Package options property for package - ptomulik 







 h2. (#23084) Package options property for package   * Author: Paweł Tomulik   * Company: Warsaw University of Technology  * Github ID: [ptomulik|https://github.com/ptomulik]  * [Pull Request 2034 Discussion|https://github.com/puppetlabs/puppet/pull/2034]  * [Pull Request 2034 File Diff|https://github.com/puppetlabs/puppet/pull/203...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group an

Jira (PUP-671) PR (2034): (#23084) Package options property for package - ptomulik

2014-01-04 Thread gepetto-bot (JIRA) 
Title: Message Title










 

 gepetto-bot commented on an issue











 






  Re: PR (2034): (#23084) Package options property for package - ptomulik 










jantman commented:
Agree with @adrienthebo about the naming - "build options" seems like a bad name for many other providers, where these options can't affect a build (i.e. the many package management systems that only install pre-built/compiled packages). I don't know if there's a name collision, but I'd also suggest extra_options as a possibility. 












   

 Add Comment











 













 Puppet /  PUP-671



  PR (2034): (#23084) Package options property for package - ptomulik 







 h2. (#23084) Package options property for package   * Author: Paweł Tomulik   * Company: Warsaw University of Technology  * Github ID: [ptomulik|https://github.com/ptomulik]  * [Pull Request 2034 Discussion|https://github.com/puppetlabs/puppet/pull/2034]  * [Pull Request 2034 File Diff|https://github.com/puppetlabs/puppet/pull/203...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group an

Jira (PUP-1320) service puppet ensure stopped kills off cron-run puppet with "Caught TERM; calling stop"

2014-01-04 Thread Jason Antman (JIRA) 
Title: Message Title










 

 Jason Antman commented on an issue











 






  Re: service puppet ensure stopped kills off cron-run puppet with "Caught TERM; calling stop" 










After some further investigation, it looks like I have a different issue than Jo (the original reporter of this issue).
The mcollective puppet agent triggers runs with --daemonize, not with --no-daemonize. Apparently this is done to allow the mcollective process to continue without blocking for the puppet run to complete. So, I suppose, that's really an issue with the mcollective puppet agent, not puppet itself (or, maybe mco needs to run puppet with --pidfile=)?
Re: the original issue, Jo, running Puppet 3.4.1 on CentOS 6.4 I don't see this problem - if I run "puppet agent --onetime --no-daemonize", /var/run/puppet/agent.pid is not created, and `service puppet status` exits 3 with "puppet is stopped". What version of puppet are you running that exhibits this?












   

 Add Comment











 













 Puppet /  PUP-1320



  service puppet ensure stopped kills off cron-run puppet with "Caught TERM; calling stop" 







 We have recently switched from puppet agent in daemon mode (for kick) to cron-run puppet with mcollective agent. However, I started noticing that puppet policies were being inconsistently applied across the hosts. It turns out that this policy is the problem: service { 'puppet':  ensure => stopped,  enable => false,    ...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)

Jira (PUP-1244) Yum provider using "version-release" to validate installation.

2014-01-04 Thread Jason Antman (JIRA) 
Title: Message Title










 

 Jason Antman commented on an issue











 






  Re: Yum provider using "version-release" to validate installation. 










From the man page for yum 3.2.29 on CentOS 6.4: """SPECIFYING PACKAGE NAMES A package can be referred to for install, update, remove, list, info etc with any of the following as well as globs of any of the following: name name.arch name-ver name-ver-rel name-ver-rel.arch name-epoch:ver-rel.arch epoch:name-ver-rel.arch """
what we seem to be concerned with is "ver" vs "ver-rel", and perhaps globs of those values (PUP-1365).












   

 Add Comment











 













 Puppet /  PUP-1244



  Yum provider using "version-release" to validate installation. 







 When using yum provider Puppet complains(error output) when using only the version(string) of the package to install or installed at the time of verification. $snmp_version = "5.3.2.2"  package { "net-snmp": ensure => "${snmp_version}"; }Client output:debug: //Node[client.example.com]/snmp::base/Package[net-snmp]: Chan...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
You received this message because you are subscribed to the Google Groups "Pupp