Jira (PUP-1375) Kylo Test Sub-task
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
Jira (PUP-1374) Kylo Test Issue
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
Jira (PUP-1373) Kylo Test Sub-task
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
Jira (PUP-1372) Kylo Test Issue
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
Jira (PUP-1368) WIndows Scheduled Task causes seg-fault
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
Title: Message Title Geek Man updated an issue Puppet / PUP-1368 WIndows Scheduled Task causes seg-fault Change By: Geek Man InthepastdayI'veimplementedsomescheduledtaskswhichinvokeanMSSQLstoredprocedureviaSQLCMD.TodayI'vefoundthatthesescheduledtasksarecausingasegfaultonanyagentwhichtheyrun.Inalmostalltests,I'vebeenabletoruntheagentviapuppetagent--test--debug--trace.Thefirstrunwillcorrectlycreatethescheduledtask;butthesecondrunwillproduceasegfault ofthepuppetagent,causingthecatalogruntoneverfinish .Sometimesathirdrunwasneededtogetasegfault.TheaffectednodessofararebothWindows2008R2,butrunningdifferentsetsofupdates(egoneisnotSP1).BothwereoriginallyrunningPuppet3.3.1,butIupgradedoneofthemto3.4.1,whichnoeffect.I'vecreatedanew'test'moduletosimplifyreproducingthebug.TotestthisbugIamsimplyaddingincludetesttothenodedefinitionforchosennodes.I'veincludedthetestmodulemanifestforreproduction,aswellasthestackstraceIgetwhenthesegfaultoccurs. 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
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: Reportprocessorinpuppetdb-terminusfails duringcataloguecompilationfailures ifreporthasnometrics 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
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
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
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: pre service { 'puppet': ensure = stopped, enable = false, ...
This message was sent by Atlassian JIRA
Jira (PDB-106) Report processor in puppetdb-terminus fails if report has no metrics
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
Jira (PDB-106) Report processor in puppetdb-terminus fails on failed reports / reports with no metrics
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: Reportprocessorinpuppetdb-terminusfails ifreporthas onfailedreports/reportswith nometrics 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
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
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
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
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: JasonAntman 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
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: TypesandProviders 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
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
Jira (PDB-202) reports: Add a successful key with true/false
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
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
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
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: pre 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 /pre 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: pre 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
Jira (PUP-1371) puppet cannot manage agent or master after update to puppet 3.2
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 pre 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 /pre Looking into the
Jira (PUP-1320) service puppet ensure stopped kills off cron-run puppet with Caught TERM; calling stop
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
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: pre 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 the Google Groups
Jira (PUP-671) PR (2034): (#23084) Package options property for package - ptomulik
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 ptomu...@meil.pw.edu.pl * 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 and stop
Jira (PUP-671) PR (2034): (#23084) Package options property for package - ptomulik
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 ptomu...@meil.pw.edu.pl * 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 and stop
Jira (PUP-1320) service puppet ensure stopped kills off cron-run puppet with Caught TERM; calling stop
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=some different path)?
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: pre 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.
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. pre $snmp_version = 5.3.2.2 package { net-snmp: ensure = ${snmp_version}; } /pre Client output: pre 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 Puppet Bugs group.
To
