[MCollective - Feature #16319] should be able to parse natural dates
Issue #16319 has been updated by Charlie Sharpsteen. Redmine Issue [#16319](http://projects.puppetlabs.com/issues/16319) has been migrated to JIRA: https://tickets.puppetlabs.com/browse/MCO-54 Feature #16319: should be able to parse natural dates https://projects.puppetlabs.com/issues/16319#change-101434 * Author: R.I. Pienaar * Status: Accepted * Priority: Normal * Assignee: * Category: Core * Target version: 2.3.x * Keywords: * Branch: * Affected mCollective version: A natural language date parser for strings like next monday 4am should be written or used. I've used http://chronic.rubyforge.org/ a lot in the past, we should evaluate the pros and cons of either vendoring chronic or writing one for our own needs -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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.
[MCollective Plugins - Bug #16447] agent registration issue with mongodb
Issue #16447 has been updated by Charlie Sharpsteen.
Redmine Issue [#16447](http://projects.puppetlabs.com/issues/16447) has been
migrated to JIRA:
https://tickets.puppetlabs.com/browse/MCO-110
Bug #16447: agent registration issue with mongodb
https://projects.puppetlabs.com/issues/16447#change-101435
* Author: chuck scott
* Status: Accepted
* Priority: Normal
* Assignee: Richard Clamp
* Category:
* Target version:
* Keywords: mcollective mongodb
* Branch:
* Affected mCollective version: 2.0.0
In discussion with
[R.I.Pienaar](https://groups.google.com/a/puppetlabs.com/forum/?fromgroups=#!topic/pe-users/87kqLkiTUMY)
a registration issue with the
[mcollective/agent/registration.rb](https://raw.github.com/puppetlabs/mcollective-plugins/master/agent/registration-mongodb/agent/registration.rb)
plugin
leads to the following stack trace:
[chuck@stubhub-centos62-64-vm6 mcollective]$ tail -20
/var/log/mcollective.log
D, [2012-09-17T10:27:11.904649 #3918] DEBUG -- : stomp.rb:197:in `receive'
Waiting for a message from Stomp
D, [2012-09-17T10:27:11.908196 #3918] DEBUG -- : registration.rb:96:in
`handlemsg' Updated data for host stubhub-centos62-64-vm6.local with id in
0.00247311592102051s
E, [2012-09-17T10:27:11.908369 #3918] ERROR -- : agents.rb:138:in
`dispatch' Execution of registration failed: undefined method `[]' for
nil:NilClass
E, [2012-09-17T10:27:11.908454 #3918] ERROR -- : agents.rb:139:in
`dispatch' /usr/libexec/mcollective/mcollective/agent/registration.rb:91:in
`handlemsg'
/usr/lib/ruby/site_ruby/1.8/mcollective/agents.rb:126:in `dispatch'
/usr/lib/ruby/1.8/timeout.rb:67:in `timeout'
/usr/lib/ruby/site_ruby/1.8/mcollective/agents.rb:125:in `dispatch'
/usr/lib/ruby/site_ruby/1.8/mcollective/agents.rb:121:in `initialize'
/usr/lib/ruby/site_ruby/1.8/mcollective/agents.rb:121:in `new'
/usr/lib/ruby/site_ruby/1.8/mcollective/agents.rb:121:in `dispatch'
/usr/lib/ruby/site_ruby/1.8/mcollective/runner.rb:82:in `agentmsg'
/usr/lib/ruby/site_ruby/1.8/mcollective/runner.rb:55:in `run'
/usr/lib/ruby/site_ruby/1.8/mcollective/runner.rb:50:in `loop'
/usr/lib/ruby/site_ruby/1.8/mcollective/runner.rb:50:in `run'
/usr/lib/ruby/site_ruby/1.8/mcollective/unix_daemon.rb:30:in
`daemonize_runner'
/usr/lib/ruby/site_ruby/1.8/mcollective/unix_daemon.rb:13:in `daemonize'
/usr/lib/ruby/site_ruby/1.8/mcollective/unix_daemon.rb:5:in `fork'
/usr/lib/ruby/site_ruby/1.8/mcollective/unix_daemon.rb:5:in `daemonize'
/usr/lib/ruby/site_ruby/1.8/mcollective/unix_daemon.rb:20:in
`daemonize_runner'
/usr/sbin/mcollectived:43
we resolve the issue by applying the following fix:
[chuck@stubhub-centos62-64-vm6 mcollective]$ diff -u
/usr/libexec/mcollective/mcollective/agent/registration.rb
/usr/libexec/mcollective/mcollective/agent/registration.rb.orig
--- /usr/libexec/mcollective/mcollective/agent/registration.rb 2012-09-17
11:44:06.362358083 -0700
+++ /usr/libexec/mcollective/mcollective/agent/registration.rb.orig
2012-09-17 11:42:28.734447337 -0700
@@ -82,15 +82,13 @@
end
by_fqdn = {:fqdn = req[:fqdn]}
doc_id = nil
before = Time.now.to_f
begin
doc = @coll.find_and_modify(:query = by_fqdn, :update = {'$set' = req},
:new = true)
- if doc
- doc_id = doc['_id']
- else
-doc_id = @coll.insert(req, {:safe = true})
- end
+ doc_id = doc['_id']
rescue Mongo::OperationFailure
doc_id = @coll.insert(req, {:safe = true})
ensure
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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.
[MCollective - Bug #17037] inputs that are not defined in the DDL should result in an error
Issue #17037 has been updated by Charlie Sharpsteen. Redmine Issue [#17037](http://projects.puppetlabs.com/issues/17037) has been migrated to JIRA: https://tickets.puppetlabs.com/browse/MCO-55 Bug #17037: inputs that are not defined in the DDL should result in an error https://projects.puppetlabs.com/issues/17037#change-101436 * Author: R.I. Pienaar * Status: Accepted * Priority: Normal * Assignee: * Category: * Target version: 2.3.x * Keywords: * Branch: * Affected mCollective version: pre mco rpc rpcutil ping x=y /pre This should raise an error, I am marking this as a parent to the long running jobs ticket as we should only enforce this once that is supported - because users are currently building their own background job feature that relies on this behaviour. This will also break the RAL agent. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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.
[MCollective Plugins - Feature #17060] Ability to list directories in filemgr agent/app
Issue #17060 has been updated by Charlie Sharpsteen. Redmine Issue [#17060](http://projects.puppetlabs.com/issues/17060) has been migrated to JIRA: https://tickets.puppetlabs.com/browse/MCO-111 Feature #17060: Ability to list directories in filemgr agent/app https://projects.puppetlabs.com/issues/17060#change-101437 * Author: Drew Blessing * Status: Code Insufficient * Priority: Normal * Assignee: * Category: * Target version: * Keywords: * Branch: ploubser/mcollective-filemgr-agent/tree/feature/master/17060 * Affected mCollective version: 2.2.1 It would be nice to be able to list a directory with the filemgr plugin. This can be accomplished fairly easily. I have a preliminary implementation worked up. I plan to solicit some discussion on the #mcollective IRC and make additional changes before submitting a pull request. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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.
[MCollective - Feature #17065] Create a scripting environment for RPC actions
Issue #17065 has been updated by Charlie Sharpsteen. Redmine Issue [#17065](http://projects.puppetlabs.com/issues/17065) has been migrated to JIRA: https://tickets.puppetlabs.com/browse/MCO-56 Feature #17065: Create a scripting environment for RPC actions https://projects.puppetlabs.com/issues/17065#change-101438 * Author: R.I. Pienaar * Status: Accepted * Priority: High * Assignee: * Category: Backlog * Target version: * Keywords: backlog * Branch: * Affected mCollective version: As users create more and more agents and actions they want a convenient way to combine these into scripts. The RPC client libraries are ok for this though they're optimised for really short scripts mostly communicating with just one agent. But primarily they require you to know ruby and there are a large number of Puppet users who know Puppet but not ruby. We should create something to allow series of requests: * Conveniently call out to different agents and actions * Create relationships between action calls * Be a simplified DSL rather than something complex like ruby * Support parameters supplied on the command line I've previously written a quick prototype of this idea in https://github.com/ripienaar/puppet-mcollective and have had very regular feedback from the community that this is a desired feature. The prototype is built as a Puppet type and provider allowing the use of the Puppet DSL and its relationships, chaining, notifying, facts etc to be used to create these scripts. If we decide to use the Puppet DSL we should also consider writing a face or application to call out to these scripts to provide a convenient and natural integration. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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.
[MCollective - Refactor #17068] Refactor the plugin application
Issue #17068 has been updated by Charlie Sharpsteen. Redmine Issue [#17068](http://projects.puppetlabs.com/issues/17068) has been migrated to JIRA: https://tickets.puppetlabs.com/browse/MCO-57 Refactor #17068: Refactor the plugin application https://projects.puppetlabs.com/issues/17068#change-101439 * Author: R.I. Pienaar * Status: Accepted * Priority: Normal * Assignee: Pieter Loubser * Category: Backlog * Target version: 2.3.x * Keywords: backlog * Branch: * Affected mCollective version: The plugin application in mcollective has over time grown into a bit of a beast of inter dependant stuff, we should refactor this to be clearer code with better separation while maintaining current feature set. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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.
[MCollective - Feature #17071] Document approaches to more scalable deployes
Issue #17071 has been updated by Charlie Sharpsteen. Redmine Issue [#17071](http://projects.puppetlabs.com/issues/17071) has been migrated to JIRA: https://tickets.puppetlabs.com/browse/MCO-58 Feature #17071: Document approaches to more scalable deployes https://projects.puppetlabs.com/issues/17071#change-101440 * Author: R.I. Pienaar * Status: Investigating * Priority: Normal * Assignee: * Category: Backlog * Target version: * Keywords: backlog * Branch: * Affected mCollective version: Currently the state of art regarding complex or large mcollective sites is just to mesh all the activemqs together. This does not work well and is not a good idea given the design of ActiveMQ clustering however it seems the obvious thing so everyone does it. We need to test, document, benchmark etc a scalable mcollective deploy strategy based on ActiveMQ -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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.
[MCollective - Bug #17072] Getting started with mcollective should be easier
Issue #17072 has been updated by Charlie Sharpsteen. Redmine Issue [#17072](http://projects.puppetlabs.com/issues/17072) has been migrated to JIRA: https://tickets.puppetlabs.com/browse/MCO-59 Bug #17072: Getting started with mcollective should be easier https://projects.puppetlabs.com/issues/17072#change-101441 * Author: R.I. Pienaar * Status: Accepted * Priority: High * Assignee: R.I. Pienaar * Category: Backlog * Target version: 2.3.x * Keywords: backlog * Branch: * Affected mCollective version: Today getting going requires one to setup ActiveMQ or RabbitMQ and understanding a ton of complex technology. Additionally small sites really do not care that much for middleware, they want something simpler/easier else they just wont use mcollective. We have a number of options here to consider: * Create a easier ActiveMQ distribution with a DSL to configure it something as simple as http://p.devco.net/97/ * Investigate other kinds of middleware suitable for small sites like MongoDB, Redis etc see http://srt.ly/cj -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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.
[MCollective - Bug #17074] Use JSON for all serialization
Issue #17074 has been updated by Charlie Sharpsteen. Redmine Issue [#17074](http://projects.puppetlabs.com/issues/17074) has been migrated to JIRA: https://tickets.puppetlabs.com/browse/MCO-60 Bug #17074: Use JSON for all serialization https://projects.puppetlabs.com/issues/17074#change-101442 * Author: R.I. Pienaar * Status: Accepted * Priority: Normal * Assignee: * Category: Backlog * Target version: * Keywords: backlog * Branch: * Affected mCollective version: Today mcollective use YAML or Marshal for serialization because: * It's in all Rubies * It supports complex data types * The protocol uses symbols This is not portable, it is roughly impossible to support other languages on the mcollective protocol because this choice effectively makes it Ruby specific. We have ages ago vendored a JSON gem that works on older RHEL systems so we should consider doing everything with JSON. A few problems: * today there are users who transport complex ruby types using mcollective, this works due to the choice of yaml/marshal as serialization and we will effectively downgrade mcollective if we support pure JSON. * the protocol has to change and this will break backwards compat unless we add some magical handling for strings and symbols ala the mash gem. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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.
[MCollective - Feature #17075] Reply transformations and custom targets/outputs
Issue #17075 has been updated by Charlie Sharpsteen. Redmine Issue [#17075](http://projects.puppetlabs.com/issues/17075) has been migrated to JIRA: https://tickets.puppetlabs.com/browse/MCO-61 Feature #17075: Reply transformations and custom targets/outputs https://projects.puppetlabs.com/issues/17075#change-101443 * Author: R.I. Pienaar * Status: Accepted * Priority: Normal * Assignee: * Category: Backlog * Target version: * Keywords: backlog * Branch: * Affected mCollective version: MCollective is effectively a systems integration framework, on its own not doing a whole lot but enables you to integrate various systems around unified AAA etc. The only real output avenue today is to output to other things that speak mcollective though but this is not ideal. A simple case might be where a user wants to initiate a monitoring check on machines via mcollective but have the result go to his Nagios system direct without needing to create some mcollective - nagios translation daemon as is the current common case. We therefore need: * Configurable output formats, mcollective output format must be just one of these plugins * A way to choose one in the API and to supply it other information like the IP of the Nagios server in the example above -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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.
[MCollective - Bug #17077] Create a richer list of default data, validator and summary plugins
Issue #17077 has been updated by Charlie Sharpsteen. Redmine Issue [#17077](http://projects.puppetlabs.com/issues/17077) has been migrated to JIRA: https://tickets.puppetlabs.com/browse/MCO-62 Bug #17077: Create a richer list of default data, validator and summary plugins https://projects.puppetlabs.com/issues/17077#change-101444 * Author: R.I. Pienaar * Status: Accepted * Priority: Normal * Assignee: * Category: Backlog * Target version: * Keywords: backlog * Branch: * Affected mCollective version: We now have the ability to create custom data, validation and summary plugins but do not yet ship many. * go through existing plugins and create data, validator and summary plugins where sensible * create more statistical summary plugins - everyone knows 'average' is not really useful and we should add more sane ones * create a richer set of default validators for common things found in typical mco environments -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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.
[MCollective - Feature #17079] Actions should be categorised
Issue #17079 has been updated by Charlie Sharpsteen. Redmine Issue [#17079](http://projects.puppetlabs.com/issues/17079) has been migrated to JIRA: https://tickets.puppetlabs.com/browse/MCO-63 Feature #17079: Actions should be categorised https://projects.puppetlabs.com/issues/17079#change-101445 * Author: R.I. Pienaar * Status: Investigating * Priority: Normal * Assignee: * Category: Backlog * Target version: * Keywords: backlog * Branch: * Affected mCollective version: Actions come in many flavours: * Ones that change the systems * Ones that request status or data about the system * Ones that interact with systems like sysctl as pure information retrieval etc * Ones that can expose sensitive information and ones that dont And many more, we should allow actions to be classified into set categories so that consoles like the PE console can use information in their RBAC -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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.
[MCollective - Feature #17084] General improvements to plugins
Issue #17084 has been updated by Charlie Sharpsteen. Redmine Issue [#17084](http://projects.puppetlabs.com/issues/17084) has been migrated to JIRA: https://tickets.puppetlabs.com/browse/MCO-64 Feature #17084: General improvements to plugins https://projects.puppetlabs.com/issues/17084#change-101446 * Author: R.I. Pienaar * Status: Accepted * Priority: Normal * Assignee: * Category: Backlog * Target version: * Keywords: backlog * Branch: * Affected mCollective version: Puppet Labs maintains a bunch of plugins, these are in various states ranging from good to barely functional. We should do a full review of all the plugins: * Identify ones that should just be retired * Identify improvements that needs to be made to them esp wrt new mcollective features * Ensure they have proper test coverage and are part of the new package build system (#17070) * Create better documentation for each plugin ideally with each plugin repo and ideally automatically published on each build by #17070 * retire the wiki under mcollective-plugins repo replacing it with auto generated docs -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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.
[MCollective - Feature #17085] Create an auditing system for users sites which suggests new plugins and tips
Issue #17085 has been updated by Charlie Sharpsteen. Redmine Issue [#17085](http://projects.puppetlabs.com/issues/17085) has been migrated to JIRA: https://tickets.puppetlabs.com/browse/MCO-65 Feature #17085: Create an auditing system for users sites which suggests new plugins and tips https://projects.puppetlabs.com/issues/17085#change-101447 * Author: R.I. Pienaar * Status: Investigating * Priority: Normal * Assignee: * Category: Backlog * Target version: * Keywords: backlog * Branch: * Affected mCollective version: Users should be aware when new plugin versions, mcollective versions etc are available. Additionally we have a desire to gather metrics of usage, deployment sizes etc. One way to do both of these things in one can be seen in the mock up below: pre $ mco plugin check_update This command will gather anonymous metrics of your collective and submit them to Puppet Labs. You will get a chance to review the data prior to submission and cancel if you do not agree Continue? (y/n): y Gathering information about your site: * [ ] 26 / 26 You may review the data being sent in /tmp/xyz.json Continue? (y/n): y HINTS AND SUGGESTIONS: New major release available: You are currently running version 3.0.0 of MCollective, the current production release is 3.2.0 which delivers significant new features, please review http:// for information on this release Performance concerns: Users with a node count similar to yours generally see 'mco ping' performance of 300ms, you site is performing at 800ms and might suggest there is an oppertunity to optimise your middleware configuration etc PLUGINS: Available updates for MColective version 3.0.0 Plugin Current Avaialble 1) agent/package1.2.21.2.3 2) discovery/puppetdb Available updates for MCollective version 3.2.0 Plugin Current Avaialble 3) agent/package1.2.22.0.0 View changelog for plugin (q to quit): 1 Install and uninstall software packages Author: R.I.Pienaar Version: 3.4 License: ASL2 Timeout: 180 Home Page: https://github.com/puppetlabs/mcollective-plugins Changes in version 1.2.3 - - - Changes in version 2.0.0 - - - /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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.
[MCollective - Bug #17086] Improve client usage in more complex ruby scripts
Issue #17086 has been updated by Charlie Sharpsteen. Redmine Issue [#17086](http://projects.puppetlabs.com/issues/17086) has been migrated to JIRA: https://tickets.puppetlabs.com/browse/MCO-66 Bug #17086: Improve client usage in more complex ruby scripts https://projects.puppetlabs.com/issues/17086#change-101448 * Author: R.I. Pienaar * Status: Accepted * Priority: Normal * Assignee: * Category: Backlog * Target version: * Keywords: backlog * Branch: * Affected mCollective version: Today the typical way is to use 'include MCollective::RPC' and then use some methods added to Object. This works ok for simple cases and seems to do what most people want however there's a growing number of cases where people want to do much more complex things including multi agent scripts, web consoles, integration into other applications etc where polluting Object is a terrible idea. The RPC::Client class should have a helper that constructs a client in the same was that rpcclient() does today and we should move things like printrpc etc into the client class for this cases. The old method will continue to work, the new one would be along these lines: pre require 'mcollective' c = MCollective::RPC.client(rpcutil) c.printrpc c.ping c.printstats /pre Effectively the same thing as today except there isnt any real pollution or using of variables in the current scope etc, a simple isolated class that does what we do today via the mixin. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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.
[PuppetDB - Feature #17108] Degraded mode that allows Puppet to operate when PuppetDB is down - with queues and cache
Issue #17108 has been updated by Charlie Sharpsteen. Redmine Issue [#17108](http://projects.puppetlabs.com/issues/17108) has been migrated to JIRA: https://tickets.puppetlabs.com/browse/PDB-139 Feature #17108: Degraded mode that allows Puppet to operate when PuppetDB is down - with queues and cache https://projects.puppetlabs.com/issues/17108#change-101450 * Author: Deepak Giridharagopal * Status: Needs Decision * Priority: Normal * Assignee: * Category: * Target version: * Keywords: backlog * Branch: * Affected PuppetDB version: Many current PuppetDB users are managing HA themselves, by setting up HTTP load balancers and PostgreSQL replication on their own. Architecturally, I think we could reasonably offer application-level HA...a system that would be easier to setup, and would have relaxed consistency guarantees compared to more hardcore (and more complicated) database replication. Ideas: * the terminus code can spool write requests to disk in the event of downstream failure, and flush that queue when connectivity is re-established * the terminus code can cache collection queries for a configurable amount of time. the cache is consulted only during failure scenarios, to allow for continued (albeit degraded) operation. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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 (HI-46) Hiera should support alternate environments
Title: Message Title garrett honeycutt commented on an issue Re: Hiera should support alternate environments Separate hiera.yaml files are necessary because different environments may need different hierarchies/backends specified. Add Comment Hiera / HI-46 Hiera should support alternate environments Currently hiera supports one `hiera.yaml` file hardcoded to be in the same location as `puppet.conf` (which is the `config` puppet directive. Having separate `hiera.yaml`'s per puppet environment would go along with having separate `site.pp`'s, modules, etc. per environment. 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 (FACT-149) Implement UUID fact
Title: Message Title redmine.exporter created an issue Facter / FACT-149 Implement UUID fact Issue Type: Bug Assignee: Eric Sorenson Created: 16/Dec/13 1:40 AM Labels: redmine Priority: Normal Reporter: redmine.exporter Debian-based systems in particular (possibly others) ship with an /etc/hosts file that starts 127.0.0.1 localhost 127.0.1.1 hostname.domain.tld hostname This is used to specify the FQDN of the machine independently of its physical IP address, and I believe their expectation is that you are not required to change this. However, this breaks the hostid command that is used to provide the uniqueid fact. I would expect the uniqueid fact to be unique on out-of-the-box Debian machines - perhaps munging Facter.ipaddress in the same way as the hostid command would. I also tested CentOS, but this does not use the same hack, and it looks like you are expected to reconfigure /etc/hosts so that applications can find the hostname and FQDN. Add Comment
Jira (PUP-1030) FreeBSD: Puppet triggers loading of ZFS module
Title: Message Title redmine.exporter created an issue Puppet / PUP-1030 FreeBSD: Puppet triggers loading of ZFS module Issue Type: Bug Assignee: Unassigned Created: 16/Dec/13 1:48 AM Labels: redmine Priority: Normal Reporter: redmine.exporter When puppet starts the puppet ZFS provider issues the zfs command. On FreeBSD this automatically loads the ZFS kernel module. Even when ZFS is not used on that host. The provider should first check if ZFS is enabled or not. If it's not enabled it shouldn't execute any zpool or zfs commands as those will trigger the automatic load of the kernel module. Add Comment
Jira (PUP-1031) Improve Puppet's handling of non-ASCII character encodings
Title: Message Title redmine.exporter created an issue Puppet / PUP-1031 Improve Puppet's handling of non-ASCII character encodings Issue Type: Bug Assignee: Unassigned Created: 16/Dec/13 2:40 AM Labels: redmine customer Priority: Normal Reporter: redmine.exporter This is an umbrella bug for issues related to Puppet's handling of non-ASCII character encodings. Many of these issues crop up when running Puppet on Ruby 1.9.x and newer. See the 'related bugs' field for a full list of issues. Add Comment
Jira (PDB-28) Support for structured facts
Title: Message Title Erik Daln commented on an issue Re: Support for structured facts Both Puppet and Facter already supports it if you add --stringify_facts=false to puppet. Add Comment PuppetDB / PDB-28 Support for structured facts We keep hearing that Facter is going to start supporting structured facts at some point in the not-too-distant future. Once that happens, we will need to be able to support them in PuppetDB. Presumably this is simply a matter of storing them, which could be as simple as just serializing them to JSON and stuffing them into a varchar/text field. Howeve... 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-1033) Updated functions are not reloaded within a worker process
Title: Message Title redmine.exporter created an issue Puppet / PUP-1033 Updated functions are not reloaded within a worker process Issue Type: Bug Assignee: Unassigned Created: 16/Dec/13 2:59 AM Labels: redmine customer Priority: Normal Reporter: redmine.exporter If a custom function is updated in an environment the workers will continue to use the old version if they had that loaded already. So with multiple passenger workers you get a situation where some puppet runs use the old version of the function and some use the new version, but all use the new versions of the manifest code. To solve this the scope instance for the environment should probably be destroyed after each compilation so the new versions are always loaded in on a new compile. Or just delete the functions from the object. Add Comment
Jira (PUP-1040) Segregate client facts, server facts and ENC params in topscope hashes
Title: Message Title
redmine.exporter created an issue
Puppet / PUP-1040
Segregate client facts, server facts and ENC params in topscope hashes
Issue Type:
New Feature
Assignee:
Unassigned
Created:
16/Dec/13 3:00 AM
Labels:
redmine
Priority:
Normal
Reporter:
redmine.exporter
Having to use $operatingsystem (and soon $::operatingsystem) in our manifests is:
confusing for new users
prone to name-clashing
Those variables are really specific in Puppet because they come from the exterior.
My proposal would be to move them to separate Puppet hashes of names:
`$facts`
`$server_facts`
`$parameters`
So usage would be: pre ... firewall { http: protocol = TCP, src ="" $facts['ipaddress'] }
Jira (PUP-1037) Puppet lacks a proper undefined value
Title: Message Title redmine.exporter created an issue Puppet / PUP-1037 Puppet lacks a proper undefined value Issue Type: Bug Assignee: Unassigned Created: 16/Dec/13 3:00 AM Labels: redmine Priority: Normal Reporter: redmine.exporter $y = undef notice($y == ) # true notice($x == $y) # true notice($x == ) # true Recent changes in the Puppet DSL made equality commutative (good!), but in doing so broke work-arounds for actually testing for the difference between an undefined and empty value. The most logical fix would be to equate Puppet's `undef` with Ruby's `nil`. Add Comment
Jira (PUP-1039) Use in expressions when realizing virtual resources
Title: Message Title
redmine.exporter created an issue
Puppet / PUP-1039
Use in expressions when realizing virtual resources
Issue Type:
Bug
Assignee:
Unassigned
Created:
16/Dec/13 3:00 AM
Labels:
redmine
Priority:
Normal
Reporter:
redmine.exporter
It would be nice if you could use the in _expression_ when realizing resources. Currently the following fails:
pre @group { 'foo': ... }
@group { 'bar': ... }
$grouplist=[ 'foo', 'bar' ] Group | title in $grouplist | /pre
However using realise it works: pre @group { 'foo': ... }
@group { 'bar': ... }
$grouplist=[ 'foo', 'bar' ] realize(Group[$grouplist]) /pre
Add Comment
Jira (PUP-1036) File content should be retrievable from remote buckets other than 'puppet'
Title: Message Title
redmine.exporter created an issue
Puppet / PUP-1036
File content should be retrievable from remote buckets other than 'puppet'
Issue Type:
New Feature
Assignee:
Unassigned
Created:
16/Dec/13 3:00 AM
Labels:
redmine
Priority:
Normal
Reporter:
redmine.exporter
Overview
Currently, the only way to configure the Puppet agent to use a remote file bucket to retrieve content using the static compiler is to declare a filebucket resource named `puppet`.
precode filebucket { puppet: server = $server, path = false, }
/code/pre
I expected the following to work:
pre filebucket { filetest: server = $server, path = false, }
file { foo: ensure = file, path = /tmp/foo.txt, source = puppet:///modules/filetest/foo.txt, backup = filetest }
/pre
The reason I expected this to work is because the backup parameter is the only way to associate a file resource to a filebucket resource. I don't think the final solution of this bug should be to make the above example work because this is about retrieving content from the file bucket when using the static compiler with a static catalog.
Jira (PUP-1038) puppet fails if template contains invalid utf-8
Title: Message Title
redmine.exporter created an issue
Puppet / PUP-1038
puppet fails if template contains invalid utf-8
Issue Type:
Bug
Assignee:
Unassigned
Created:
16/Dec/13 3:00 AM
Labels:
redmine
Priority:
Normal
Reporter:
redmine.exporter
If you attempt to use a file resource with a 'content' parameter pointing at a template, and the template contains binary content, you may get an error like this:
Error: Failed to apply catalog: Parameter content failed: Munging failed for value ... invalid byte sequence in UTF-8
I've reproduced the failure in 2.7.16 and 3.x, though the error messages differ slightly between the two (and also depending on whether you repro via 'apply' or via master/agent run).
I'm attaching the binary file that I'm using to repro. Save it into a directory structure like this:
modules/mymod/templates/mytemplate.erb
Add the modules directory to your module path and then you can repro with the following manifest:
file { /tmp/myfile: mode = 755, content = template(mymod/mytemplate.erb), }
Note that if you use the 'source' parameter rather than the 'content' parameter (and avoid calling the template function), the manifest can be applied successfully; so the issue is when bringing in binary data as a string.
Jira (PUP-1034) Caller class name variable
Title: Message Title redmine.exporter created an issue Puppet / PUP-1034 Caller class name variable Issue Type: New Feature Assignee: Unassigned Created: 16/Dec/13 3:00 AM Labels: redmine Priority: Normal Reporter: redmine.exporter It would sometimes be nice to have a $caller_class_name variable similar to the $caller_module_name but containing the full class name of the caller and not just the module name. Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
Jira (PUP-1035) Default setting for pluginsource problematic for deployments using SRV records
Title: Message Title redmine.exporter created an issue Puppet / PUP-1035 Default setting for pluginsource problematic for deployments using SRV records Issue Type: Bug Assignee: Unassigned Created: 16/Dec/13 3:00 AM Labels: redmine Priority: Normal Reporter: redmine.exporter The current default for the `pluginsource` setting is `puppet://$server/plugins`. This works well with a `server` set, but in deployments that utilize 3.0's SRV record feature, the `server` setting is likely not utilized at all for communication with a master, and will often be unset. If SRV records are in use the `pluginsource` still gets filled in with the contents of the `server` setting - and if it's unset, then the default is `puppet`. This causes failure of the pluginsync process, which is a non-fatal error for the agent run: Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate: getaddrinfo: Name or service not known Error: /File[/var/lib/puppet/lib]: Could not evaluate: getaddrinfo: Name or service not known Could not retrieve file metadata for puppet://puppet/plugins: getaddrinfo: Name or service not known I believe that changing the default setting for `pluginsource` from `puppet://$server/plugins` to `puppet:///plugins` is functionally equivalent for 'normal' deployments not running `use_srv_records`, while it will cause the pluginsync process to find a working master in cases where `use_srv_records` is utilized. Simply setting `pluginsource = puppet:///plugins` is an effective workaround for SRV record deployments in the interim.
Jira (PUP-1041) naginator not parsing blank parameters
Title: Message Title
redmine.exporter created an issue
Puppet / PUP-1041
naginator not parsing blank parameters
Issue Type:
Bug
Assignee:
Unassigned
Created:
16/Dec/13 3:01 AM
Labels:
redmine
Priority:
Normal
Reporter:
redmine.exporter
Even though it wrote it, and is valid nagios syntax, The Naginator can not parse this:
define host { host_name gib-proxytest parents hostgroups gib use linux-server address 10.3.100.72 alias proxytest }
Where the parents value is blank. It borks with:
err: Could not prefetch nagios_host provider 'naginator': Could not parse configuration for nagios_host: line 62: syntax error at ' ' in /etc/nagios/nagios_host.cfg
And then rebuilds the file from scratch every time.
Add Comment
Jira (PUP-1042) Puppet apply runmode should write classes.txt file
Title: Message Title redmine.exporter created an issue Puppet / PUP-1042 Puppet apply runmode should write classes.txt file Issue Type: Bug Assignee: Unassigned Created: 16/Dec/13 3:01 AM Labels: redmine Priority: Normal Reporter: redmine.exporter Overview # The classes.txt file is only written when running Puppet in the agent run mode. It would be useful for integration with MCollective filtering if this file were also written when running Puppet the stand alone apply run mode. pre The file in which puppet agent stores a list of the classes associated with the retrieved configuration. Can be loaded in the separate `puppet` executable using the `--loadclasses` option. The default value is '$statedir/classes.txt'. classfile =
Jira (PUP-1044) FileBucket should not keep files in memory
Title: Message Title redmine.exporter created an issue Puppet / PUP-1044 FileBucket should not keep files in memory Issue Type: New Feature Assignee: Unassigned Created: 16/Dec/13 3:02 AM Labels: redmine Priority: Normal Reporter: redmine.exporter It should not be necessary to load entire files into memory to checksum them. Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
Jira (PUP-1043) Specifying file content by checksum should not use 'content' property
Title: Message Title redmine.exporter created an issue Puppet / PUP-1043 Specifying file content by checksum should not use 'content' property Issue Type: Bug Assignee: Unassigned Created: 16/Dec/13 3:02 AM Labels: redmine Priority: Normal Reporter: redmine.exporter Rather than passing around the contents of a file (e.g. in logs) we use the checksum; to support this the users is also allowed to specify the contents as a checksum, but this leads to an ambiguity when the actual contents match the checksum pattern. Instead of trying to do magic, we should have distinct syntax for referring to the contents by checksum (which should always expect a valid checksum) and for specifying the contents literally (which shouldn't do anything different if the contents happen to resemble a checksum). Add Comment
Jira (PUP-1036) File content should be retrievable from remote buckets other than 'puppet'
Title: Message Title
Erik Daln updated an issue
Puppet / PUP-1036
File content should be retrievable from remote buckets other than 'puppet'
Change By:
Erik Daln
#OverviewCurrently,theonlywaytoconfigurethePuppetagenttousearemotefilebucketto_retrieve_contentusingthestaticcompileristodeclareafilebucketresourcenamed`puppet`. pre { code } filebucket{puppet:server=$server,path=false,} / { code /pre } Iexpectedthefollowingtowork: pre {code} filebucket{filetest:server=$server,path=false,}file{foo:ensure=file,path=/tmp/foo.txt,source=puppet:///modules/filetest/foo.txt,backup=filetest} /pre {code} ThereasonIexpectedthistoworkisbecausethebackupparameteristheonlywaytoassociateafileresourcetoafilebucketresource.Idon'tthinkthefinalsolutionofthisbugshouldbetomaketheaboveexampleworkbecausethisisabout_retrieving_contentfromthefilebucketwhenusingthestaticcompilerwithastaticcatalog.
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-1042) Puppet apply runmode should write classes.txt file
Title: Message Title
Erik Daln updated an issue
Puppet / PUP-1042
Puppet apply runmode should write classes.txt file
Change By:
Erik Daln
#Overview#Theclasses.txtfileisonlywrittenwhenrunningPuppetintheagentrunmode.ItwouldbeusefulforintegrationwithMCollectivefilteringifthisfilewerealsowrittenwhenrunningPuppetthestandaloneapplyrunmode. pre {code} #Thefileinwhichpuppetagentstoresalistoftheclasses#associatedwiththeretrievedconfiguration.Canbeloadedin#theseparate`puppet`executableusingthe`--loadclasses`#option.#Thedefaultvalueis'$statedir/classes.txt'.classfile=/var/lib/puppet/state/classes.txt /pre {code} ThiswouldbeusefulwithMCollective'sconfigurationsettingof:classesfile=/var/lib/puppet/state/classes.txt#ImpactData#Atleastonecommunitymemberhasrequestedthisfeature.(Seecommentsbelow).Thisticketisimportantformcollectiveintegrationwithpuppetapply.
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-1040) Segregate client facts, server facts and ENC params in topscope hashes
Title: Message Title
Erik Daln updated an issue
Puppet / PUP-1040
Segregate client facts, server facts and ENC params in topscope hashes
Change By:
Erik Daln
Havingtouse$operatingsystem(andsoon$::operatingsystem)inourmanifestsis:*confusingfornewusers*pronetoname-clashingThosevariablesarereallyspecificinPuppetbecausetheycomefromtheexterior.MyproposalwouldbetomovethemtoseparatePuppethashesofnames:*`$facts`*`$server_facts`*`$parameters`Sousagewouldbe: pre {code} ...firewall{http:protocol=TCP,src=$facts['ipaddress']}file{/etc/issue.net:content=Thishostisin${server_facts['environment']}environment}... /pre {code} Wecouldalsohavesomecustommethodsinthetemplatewrapperssoaccessingfactsintemplatescouldbeeveneasiers,like`facts['ipaddress']`.Ofcoursetohelpmigrateusers,thefirstreleasewouldalsoputthefacts/serverfactsandparametersinthenodetopscope(andissueadeprecationwarningonlookup).
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-1045) No way to set default tags for exported ressources
Title: Message Title
redmine.exporter created an issue
Puppet / PUP-1045
No way to set default tags for exported ressources
Issue Type:
Bug
Assignee:
Unassigned
Created:
16/Dec/13 3:11 AM
Labels:
redmine
Priority:
Normal
Reporter:
redmine.exporter
Hi,
In our manifest, we are trying to set a default tag for all our Nagios_host, to achieve this we are adding the following code in the site.pp:
pre Nagios_host { tag = 'local', }
/pre
And the somewhere else in our code, we are exporting the resources and the trying to collect them using the tag:
pre @@nagios_host {'foo': params}
Nagios_host | tag == 'local' | /pre
The problem here is that, nothing is realized because the tag is not exported properly, querying puppetdb directly shows the following:
pre
curl localhost:8080/v3/resources/Nagios_host [ { parameters : { statusmap_image : os/Ubuntu.png, action_url : /pnp4nagios/graph?host=$HOSTNAME$, notifications_enabled : 1, target : /etc/icinga/objects/hosts/host-mon2.example.com.cfg, check_command : check-host-alive, address : 192.168.3.129, icon_image : os/Ubuntu.png, notification_period : 24x7, max_check_attempts : 4, tag : local, hostgroups : default, ensure : present, icon_image_alt : Ubuntu }
, line : 78,
Jira (PUP-1046) puppet module generate should produce a skeleton spec test
Title: Message Title redmine.exporter created an issue Puppet / PUP-1046 puppet module generate should produce a skeleton spec test Issue Type: New Feature Assignee: Unassigned Created: 16/Dec/13 4:00 AM Labels: redmine Priority: Normal Reporter: redmine.exporter Overview # In order to make `rake spec` give meaningful feedback with a module generated using `puppet module generate` once #11285 is implemented, the generate action should produce an example rspec-puppet based spec test for the module. I think the example could simply add the class to the catalog and make sure it got added. Add Comment
Jira (PUP-1047) augeas type - allow an 'if' statement in the minilanguage for changes
Title: Message Title
redmine.exporter created an issue
Puppet / PUP-1047
augeas type - allow an 'if' statement in the minilanguage for changes
Issue Type:
Bug
Assignee:
Unassigned
Created:
16/Dec/13 4:53 AM
Labels:
redmine
Priority:
Normal
Reporter:
redmine.exporter
Currently, it is only possible to turn an augeas resource on or off in its entirety by using the 'onlyif' parameter. Often, it is desirable to make different kinds of changes depending on what the augeas tree looks like precisely. For example, if in some file the setting 'foo' is not set to '1', check whether the setting exists already; if so, jjust change its value to '1'. If not, create the setting and a comment about it; as a rough draft, this would could be written in the following manner:
pre augeas { fiddle-foo: context = ... changes = if match foo size == 0 then set foo '1' ins #comment before foo set #comment[following-sibling::*[1][label() = 'foo']] 'modified by puppet' else set foo '1' end _onlyif_ = get foo != '1' }
/pre
Add Comment
Jira (PUP-1048) PR (2161): (#21641) Windows puppet service should log to the eventlog - glennsarti
Title: Message Title gepetto-bot created an issue Puppet / PUP-1048 PR (2161): (#21641) Windows puppet service should log to the eventlog - glennsarti Issue Type: Task Assignee: Unassigned Components: Community Created: 16/Dec/13 4:55 AM Labels: github Priority: Normal Reporter: gepetto-bot (#21641) Windows puppet service should log to the eventlog Author: Company: Github ID: glennsarti Pull Request 2161 Discussion Pull Request 2161 File Diff Pull Request Description
Jira (PUP-650) PR (2025): (#21641) Windows puppet service should log to the eventlog - glennsarti
Title: Message Title gepetto-bot commented on an issue Re: PR (2025): (#21641) Windows puppet service should log to the eventlog - glennsarti glennsarti commented: Raised Pull Request 2161 for these changes. https://github.com/puppetlabs/puppet/pull/2161 Add Comment Puppet / PUP-650 PR (2025): (#21641) Windows puppet service should log to the eventlog - glennsarti h2. (#21641) Windows puppet service should log to the eventlog * Author: * Company: * Github ID: [glennsarti|https://github.com/glennsarti] * [Pull Request 2025 Discussion|https://github.com/puppetlabs/puppet/pull/2025] * [Pull Request 2025 File Diff|https://github.com/puppetlabs/puppet/pull/2025/files] h2. Pull Request Description The... 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
Jira (PUP-1049) Windows puppet service should log to the eventlog
Title: Message Title redmine.exporter created an issue Puppet / PUP-1049 Windows puppet service should log to the eventlog Issue Type: Bug Assignee: Unassigned Created: 16/Dec/13 4:59 AM Labels: redmine Priority: Normal Reporter: redmine.exporter The windows service code (daemon.rb) logs to a file, since that was implemented prior to eventlog support. Now that we have the latter, the daemon code should use it, e.g. pre require 'win32/eventlog' eventlog = Win32::EventLog.open(Application) eventlog.report_event( :source = Puppet, :event_type = Win32::EventLog::INFO, # or WARN, ERROR :event_id = 0x01, # or 0x02, 0x03 :data ="" the message ) eventlog.close /pre Add Comment
Jira (PUP-1047) augeas type - allow an 'if' statement in the minilanguage for changes
Title: Message Title Dominic Cleal updated an issue Puppet / PUP-1047 augeas type - allow an 'if' statement in the minilanguage for changes Change By: Dominic Cleal Issue Type: Bug NewFeature 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-1049) Windows puppet service should log to the eventlog
Title: Message Title
Glenn Sarti updated an issue
Puppet / PUP-1049
Windows puppet service should log to the eventlog
Change By:
Glenn Sarti
Thewindowsservicecode(daemon.rb)logstoafile,sincethatwasimplementedpriortoeventlogsupport.Nowthatwehavethelatter,thedaemoncodeshoulduseit,e.g. pre {{monospaced}} require'win32/eventlog'eventlog=Win32::EventLog.open(Application)eventlog.report_event(:source=Puppet,:event_type=Win32::EventLog::INFO,#orWARN,ERROR:event_id=0x01,#or0x02,0x03:data=themessage)eventlog.close /pre {{monospaced}}
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-1050) ssh_authorized_key always changes from root to user on every run
Title: Message Title
redmine.exporter created an issue
Puppet / PUP-1050
ssh_authorized_key always changes from root to user on every run
Issue Type:
Bug
Assignee:
Unassigned
Created:
16/Dec/13 5:04 AM
Labels:
redmine
Priority:
Normal
Reporter:
redmine.exporter
I have this in my manifest:
ssh_authorized_key { test : user = root2, ensure = present, type = ssh-rsa, key = snip ==; }
Whenever I run puppet it shows these notices:
notice: /Stage[main]/Ssh/Ssh_authorized_key[test]/user: user changed 'root' to 'root2'
Is there anyway to suppress this notice? It shouldn't really be firing on each run.
Add Comment
Jira (PUP-1049) Windows puppet service should log to the eventlog
Title: Message Title
Glenn Sarti updated an issue
Puppet / PUP-1049
Windows puppet service should log to the eventlog
Change By:
Glenn Sarti
Thewindowsservicecode(daemon.rb)logstoafile,sincethatwasimplementedpriortoeventlogsupport.Nowthatwehavethelatter,thedaemoncodeshoulduseit,e.g.{ { quote} require'win32/eventlog'eventlog=Win32::EventLog.open(Application)eventlog.report_event(:source=Puppet,:event_type=Win32::EventLog::INFO,#orWARN,ERROR:event_id=0x01,#or0x02,0x03:data=themessage)eventlog.close {quote } }
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-1049) Windows puppet service should log to the eventlog
Title: Message Title
Glenn Sarti updated an issue
Puppet / PUP-1049
Windows puppet service should log to the eventlog
Change By:
Glenn Sarti
Thewindowsservicecode(daemon.rb)logstoafile,sincethatwasimplementedpriortoeventlogsupport.Nowthatwehavethelatter,thedaemoncodeshoulduseit,e.g.{{ monospaced}} require'win32/eventlog'eventlog=Win32::EventLog.open(Application)eventlog.report_event(:source=Puppet,:event_type=Win32::EventLog::INFO,#orWARN,ERROR:event_id=0x01,#or0x02,0x03:data=themessage)eventlog.close {{monospaced }}
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-1050) ssh_authorized_key always changes from root to user on every run
Title: Message Title Jrgen Weber commented on an issue Re: ssh_authorized_key always changes from root to user on every run I have this issue also. Versions: facter 1.7.3-1puppetlabs1 Ruby module for collecting simple facts about a host operating system hiera 1.2.1-1puppetlabs1 A simple pluggable Hierarchical Database. puppet 3.3.2-1puppetlabs1 Centralized configuration management - agent startup and compatibility scripts puppet-common 3.3.2-1puppetlabs1 Centralized configuration management puppetlabs-release 1.0-7 Package to install Puppet Labs gpg key and apt repo ruby-rgen 0.6.5-1puppetlabs1 A framework supporting Model Driven Software Development (MDSD) vim-puppet 3.3.2-1puppetlabs1 syntax highlighting for puppet manifests in vim and here are the logs: Mon Dec 16 12:56:32 + 2013 /Stage[main]/Profile_user/Profile_user::Usr[jweber]/Component_user::User[jweber]/Ssh_authorized_key[jweber]/key (notice): key changed 'insert pub key' Mon Dec 16 12:56:32 + 2013 /Stage[main]/Profile_user/Profile_user::Usr[jweber]/Component_user::User[jweber]/Ssh_authorized_key[jweber]/user (notice): user changed 'root' to 'jweber' Mon Dec 16 12:56:32 + 2013 /Stage[main]/Profile_user/Profile_user::Usr[jweber]/Component_user::User[jweber]/Ssh_authorized_key[jweber]/target (notice): target changed '/root/.ssh/authorized_keys' to '/home/jweber/.ssh/authorized_keys' Mon Dec 16 12:56:32 + 2013 /Stage[main]/Profile_user/Profile_user::Usr[jweber]/Component_user::User[jweber]/Ssh_authorized_key[jweber]/options (notice): undefined 'options' from 'no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command=echo 'Please login as the user \,ubuntu' Mon Dec 16 12:56:33 + 2013 Puppet (err): Puppet::Util::FileType::FileTypeFlat could not write /root/.ssh/authorized_keys: Permission denied - /root/.ssh/authorized_keys Mon Dec 16 12:56:33 + 2013 /Stage[main]/Profile_user/Profile_user::Usr[jweber]/Component_user::User[jweber]/Ssh_authorized_key[jweber] (err): Could not evaluate: Puppet::Util::FileType::FileTypeFlat could not write /root/.ssh/authorized_keys: Permission denied - /root/.ssh/authorized_keys Mon Dec 16 12:57:29 + 2013 Puppet (notice): Finished catalog run in 154.52 seconds To understand our environment we all login as users with keys and then we sudo to root if necessary. To run puppet one users 'sudo su -' and then runs puppet. I explain this because I feel the issue is environment related. It looks like to me that it is attempting to update the current users home env settings (root) as the user that was logged in via ssh (jweber). So as you can see it fails with permission errors but I do not understand the why it is even trying to do this? Sometimes it does not happen when you run puppet manually on the command line (but other times you do) and I can not work out why it does or does not happen. You can see this in the agent logs consistently but then again, sometimes it doesn't so it consistently as well. I am not sure if it is a puppet bug or something else but I started some searching and found this ticket. If you would like more information feel free to ask. Thanks Add Comment
Jira (PUP-1051) gem package provider is confused by platform components in version strings
Title: Message Title
redmine.exporter created an issue
Puppet / PUP-1051
gem package provider is confused by platform components in version strings
Issue Type:
Bug
Assignee:
Unassigned
Created:
16/Dec/13 5:15 AM
Labels:
redmine
Priority:
Normal
Reporter:
redmine.exporter
Using:
package {'facter': ensure = latest, provider = 'gem', source = http://puppet:8808, }
Produces:
notice: /Stage[main]/Common_puppet::Hpux/Package[facter]/ensure: ensure changed '1.6.17' to '1.6.17 ruby'
This happens on every puppet run.
Add Comment
Jira (PUP-1050) ssh_authorized_key always changes from root to user on every run
Title: Message Title
Jrgen Weber commented on an issue
Re: ssh_authorized_key always changes from root to user on every run
I would like to add that the user above, changes as per the user that has logged in via ssh and attempts again to overwrite root. Thanks
Add Comment
Puppet / PUP-1050
ssh_authorized_key always changes from root to user on every run
I have this in my manifest: ssh_authorized_key { test : user = root2, ensure = present, type = ssh-rsa, key = snip ==; } Whenever I run puppet it shows these notices: notice: /Stage[main]/Ssh/Ssh_authorized_key[test]/user: user changed 'root' to 'root2' Is there anyway to suppress t...
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-1052) Allow logging of package type operations
Title: Message Title redmine.exporter created an issue Puppet / PUP-1052 Allow logging of package type operations Issue Type: New Feature Assignee: Unassigned Created: 16/Dec/13 5:24 AM Labels: redmine Priority: Normal Reporter: redmine.exporter Currently, package type operations (at least with the apt provider) only log the failed command, but not the stdout/stderr of said command. It would be very helpful in debugging issues if the package type would log the output of called commands, at least when errors occur. Something similar to the log_output parameter of the exec type would be helpful. Add Comment
Jira (PUP-1053) Resource defaults and automatic tags are applied after collectors are evaluated
Title: Message Title
redmine.exporter created an issue
Puppet / PUP-1053
Resource defaults and automatic tags are applied after collectors are evaluated
Issue Type:
Bug
Assignee:
Unassigned
Created:
16/Dec/13 5:36 AM
Labels:
redmine customer
Priority:
Normal
Reporter:
redmine.exporter
Resources (and virtual resources) are not having their classes declared tags correctly applied. (Add the specified tags to the containing class or definition. All contained objects will then acquire that tag, also. ref: http://docs.puppetlabs.com/references/latest/function.html#tag)
pre class foo { tag 'notworking' notify { I'm untagged: }
notify { I'm tagged: tag = notworking }
} include foo Notify | tag == notworking | { message = I am though } /pre Results in: pre mauve /home/jbooth puppet tagmagic.pp notice: I am though notice: //foo/Notify[I'm tagged]/message: defined 'message' as 'I am though' notice: I'm untagged notice: //foo/Notify[I'm untagged]/message: defined 'message' as 'I'm untagged' /pre You can change the 'tag == foo' and life doesn't get any better. The neither notify gets the message changed. pre mauve /home/jbooth tail -1 tagmagic.pp Notify | tag == foo | { message = I am though }
mauve /home/jbooth puppet tagmagic.pp notice: I'm untagged notice: //foo/Notify[I'm untagged]/message: defined 'message' as 'I'm untagged' notice: I'm tagged notice: //foo/Notify[I'm tagged]/message: defined 'message' as 'I'm tagged' /pre
Jira (PUP-1054) Services should support 'reload' in addition to 'restart'
Title: Message Title redmine.exporter created an issue Puppet / PUP-1054 Services should support 'reload' in addition to 'restart' Issue Type: New Feature Assignee: Unassigned Created: 16/Dec/13 5:37 AM Labels: redmine Priority: Normal Reporter: redmine.exporter currently if a service needs kicking (e.g. a config file changed) you can notify the service, but this leads to a restart. It would be nice if a reload was done if the service was already running (although I suppose there are bound to be some services which require restarts for some files, reloads for others). A reload would be far faster (shorter service interruption) and potentially more robust. I'm looking at this since bind stop/start (I hadn't set hasrestart) on Debian etch can fail - it looks like stop command doesn't wait for bind to exit (I'll raise a bug with Debian about that) Add Comment
Jira (PUP-1055) invalid byte sequence with service provider upstart
Title: Message Title redmine.exporter created an issue Puppet / PUP-1055 invalid byte sequence with service provider upstart Issue Type: Bug Assignee: Unassigned Created: 16/Dec/13 5:38 AM Labels: redmine Priority: Normal Reporter: redmine.exporter I am sometimes getting invalid byte sequence in US-ASCII when using the Service type with the upstart provider. (I am not manually setting `provider = 'upstart'`, it is being set based on OS detection). The problem seems to randomly pop up, and then goes away on its own. I did manage to capture the output of `agent --trace` during one run when the issue occurred. This is with Ubuntu 12.04.1 and ruby 1.9.3-p0 pre Error: /Stage[main]/Ipa::Client::Basic/Service[sssd]: Could not evaluate: invalid byte sequence in US-ASCII /usr/lib/ruby/vendor_ruby/puppet/provider/service/upstart.rb:204:in `match' /usr/lib/ruby/vendor_ruby/puppet/provider/service/upstart.rb:204:in `match' /usr/lib/ruby/vendor_ruby/puppet/provider/service/upstart.rb:204:in `block in enabled_post_0_9_0?' /usr/lib/ruby/vendor_ruby/puppet/provider/service/upstart.rb:203:in `each_line' /usr/lib/ruby/vendor_ruby/puppet/provider/service/upstart.rb:203:in `enabled_post_0_9_0?' /usr/lib/ruby/vendor_ruby/puppet/provider/service/upstart.rb:101:in `enabled?' /usr/lib/ruby/vendor_ruby/puppet/type/service.rb:56:in `retrieve' /usr/lib/ruby/vendor_ruby/puppet/type.rb:1027:in `block in retrieve' /usr/lib/ruby/vendor_ruby/puppet/type.rb:1022:in `each' /usr/lib/ruby/vendor_ruby/puppet/type.rb:1022:in `retrieve' /usr/lib/ruby/vendor_ruby/puppet/type.rb:1041:in `retrieve_resource' /usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:32:in `perform_changes'
Jira (PUP-1056) puppet master should not trap SIGINT
Title: Message Title redmine.exporter created an issue Puppet / PUP-1056 puppet master should not trap SIGINT Issue Type: Bug Assignee: Unassigned Created: 16/Dec/13 5:39 AM Labels: redmine Priority: Normal Reporter: redmine.exporter Puppet master currently traps SIGINT. This causes problems with rack servers, especially unicorn. Unicorn has it's own SIGINT trap and will shut down the worker processes when it receives it. However because puppet master is trapping SIGINT, unicorn doesn't get the signal, the worker processes are abandoned, and then die once they hit a timeout they have in them. Because the workers are also listening for connections, you cannot start unicorn back up until all the workers die (since it can't bind to the socket). The offending code is here: https://github.com/puppetlabs/puppet/blob/b3bcb6dd385a5a9bca88c56b0e454eac9ac33dcc/lib/puppet/application/master.rb#L142 Add Comment
Jira (PUP-958) PR (2137): (#23316) Updated yum package provider to support :holdable feature by - fatmcgav
Title: Message Title gepetto-bot commented on an issue Re: PR (2137): (#23316) Updated yum package provider to support :holdable feature by - fatmcgav fatmcgav commented: @zaphod42 I've added a couple of initial test cases to check for method responses. I'm not sure how best to stub the 'yum versionlock' command call to test for the ':holdable' feature. Add Comment Puppet / PUP-958 PR (2137): (#23316) Updated yum package provider to support :holdable feature by - fatmcgav h2. (#23316) Updated yum package provider to support :holdable feature by * Author: Gavin Williams fatmc...@gmail.com * Company: * Github ID: [fatmcgav|https://github.com/fatmcgav] * [Pull Request 2137 Discussion|https://github.com/puppetlabs/puppet/pull/2137] * [Pull Request 2137 File Diff|https://github.com/puppetlabs/puppet/pull/2137/files] h... 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
Jira (PUP-480) Complete handling of undef/nil
Title: Message Title Henrik Lindberg commented on an issue Re: Complete handling of undef/nil PUP-1037 is from redmine. PUP-480 is about handling undefined in the future evaluator Add Comment Puppet / PUP-480 Complete handling of undef/nil A decision needs to be made regarding handling of undef as nil. There is agreement that it should be handled as a nil value everywhere except one case; when setting an attribute value. Currently setting undef as an attribute value has the meaning do not set this attribute (as opposed to set this attribute to nil) - which has the effect of selectin... 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-1039) Use in expressions when realizing virtual resources
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-1039 Use in expressions when realizing virtual resources Change By: Henrik Lindberg Labels: DSLpuppetdb redmine 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-1039) Use in expressions when realizing virtual resources
Title: Message Title
Henrik Lindberg commented on an issue
Re: Use in expressions when realizing virtual resources
The restrictions in what can be used as query operators in virtual and exported queries is determined by the query API. The entire query mechanism needs an overhaul (including the backends / Puppet DB) in order to provide more flexibility (i.e. additional operators).
This also relates to issues with desire to do something with the result (as opposed to just realizing, or overriding parameter values) - functionality that also requires an overhaul.
Add Comment
Puppet / PUP-1039
Use in expressions when realizing virtual resources
It would be nice if you could use the in _expression_ when realizing resources. Currently the following fails: pre @group{ 'foo': ... } @group{ 'bar': ... } $grouplist=[ 'foo', 'bar' ] Group | title in $grouplist | /pre However using realise it works: pre @group{ 'foo': ... } @group{ 'bar': ... } $grouplist=[ 'foo', 'bar' ] realiz...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google
Jira (PUP-1057) Remove 'collect' and 'select' iterative function stubs
Title: Message Title Henrik Lindberg created an issue Puppet / PUP-1057 Remove 'collect' and 'select' iterative function stubs Issue Type: Improvement Assignee: Unassigned Components: DSL Created: 16/Dec/13 7:36 AM Fix Versions: 4.0.0 Priority: Normal Reporter: Henrik Lindberg The functions 'select' and 'collect' are currently stubs that raise an error (to help those using the future parser from 3.5 migrate their code). In 4.0.0 those stubs should be removed. Add Comment
Jira (PDB-106) Report processor in puppetdb-terminus fails during catalogue compilation failures
Title: Message Title
Daniele Sluijters updated an issue
PuppetDB / PDB-106
Report processor in puppetdb-terminus fails during catalogue compilation failures
Change By:
Daniele Sluijters
Samplecontent: pre {code} nodepuppetdb1.vm{somesyntaxerror} /pre {code} Whenthereportsubmittertriestosubmitsuchareport,weget: pre {{ Feb1819:15:31puppetdb1puppet-master[28878]:Reportprocessorfailed:undefinedmethod`[]'fornil:NilClass }} /pre Onthepuppetmaster...
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 (HI-115) hiera recursive guard
Title: Message Title
redmine.exporter created an issue
Hiera / HI-115
hiera recursive guard
Issue Type:
Bug
Assignee:
Eric Sorenson
Created:
16/Dec/13 7:48 AM
Labels:
redmine
Priority:
Normal
Reporter:
redmine.exporter
The recursive guard is activated if the same variable is referenced twice. For example:
global.yaml a: '% {b} - %{b}
'
hiera a /usr/lib/ruby/vendor_ruby/hiera/recursive_guard.rb:13:in `check': Detected in [b] (Hiera::InterpolationLoop)
Also the error message is not very informative.
Add Comment
Jira (PUP-1058) puppet apply loading facts twice
Title: Message Title
redmine.exporter created an issue
Puppet / PUP-1058
puppet apply loading facts twice
Issue Type:
Bug
Assignee:
Unassigned
Created:
16/Dec/13 7:52 AM
Labels:
redmine
Priority:
Normal
Reporter:
redmine.exporter
given the site.pp with:
pre node default { notice(Busy compiling catalog) }
/pre
and a module dir setup like:
pre % mkdir modules % puppet module install ripienaar-concat --modulepath=`pwd`/modules /pre
I have no config so its all defaults:
pre % puppet apply --configprint config /home/rip/.puppet/puppet.conf % cat /home/rip/.puppet/puppet.conf cat: /home/rip/.puppet/puppet.conf: No such file or directory /pre
Running puppet 3.0.0rc7 will load facts twice:
pre % puppet apply --modulepath=`pwd`/modules `pwd`/site.pp --verbose Info: Loading facts in /home/rip/temp/modules/concat/lib/facter/concat_basedir.rb Scope(Node[dev1.devco.net]): Compiling catalog Info: Loading facts in /home/rip/temp/modules/concat/lib/facter/concat_basedir.rb Info: Applying configuration version '1348574505' Finished catalog run in 0.17 seconds /pre
But puppet 2.7.17 with the same code does:
pre info: Loading facts in /home/rip/temp/modules/concat/lib/facter/concat_basedir.rb notice: Scope(Node[default]): Compiling catalog info: Applying configuration version '1348574599' info: Creating state file
Jira (PUP-1058) puppet apply loading facts twice
Title: Message Title
Erik Daln updated an issue
Puppet / PUP-1058
puppet apply loading facts twice
Change By:
Erik Daln
giventhesite.ppwith: pre {code} nodedefault{notice(Busycompilingcatalog)} /pre {code} andamoduledirsetuplike: pre {code} %mkdirmodules%puppetmoduleinstallripienaar-concat--modulepath=`pwd`/modules /pre {code} Ihavenoconfigsoitsalldefaults: pre {code} %puppetapply--configprintconfig/home/rip/.puppet/puppet.conf%cat/home/rip/.puppet/puppet.confcat:/home/rip/.puppet/puppet.conf:Nosuchfileordirectory /pre {code} Runningpuppet3.0.0rc7willloadfactstwice: pre {code} %puppetapply--modulepath=`pwd`/modules`pwd`/site.pp--verboseInfo:Loadingfactsin/home/rip/temp/modules/concat/lib/facter/concat_basedir.rbScope(Node[dev1.devco.net]):CompilingcatalogInfo:Loadingfactsin/home/rip/temp/modules/concat/lib/facter/concat_basedir.rbInfo:Applyingconfigurationversion'1348574505'Finishedcatalogrunin0.17seconds /pre {code} Butpuppet2.7.17withthesamecodedoes: pre {code} info:Loadingfactsin/home/rip/temp/modules/concat/lib/facter/concat_basedir.rbnotice:Scope(Node[default]):Compilingcataloginfo:Applyingconfigurationversion'1348574599'info:Creatingstatefile/home/rip/.puppet/var/state/state.yamlnotice:Finishedcatalogrunin0.05seconds /pre {code}
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,
Jira (PUP-1058) puppet apply loading facts twice
Title: Message Title Erik Daln updated an issue Puppet / PUP-1058 puppet apply loading facts twice Change By: Erik Daln Affects Version/s: 3.x 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-1059) PR (2162): (#16570) Don't load the node object again in configurer - dalen
Title: Message Title gepetto-bot created an issue Puppet / PUP-1059 PR (2162): (#16570) Don't load the node object again in configurer - dalen Issue Type: Task Assignee: Unassigned Components: Community Created: 16/Dec/13 7:57 AM Labels: github Priority: Normal Reporter: gepetto-bot (#16570) Don't load the node object again in configurer Author: Erik Daln erik.gustav.da...@gmail.com Company: Spotify Github ID: dalen Pull Request 2162 Discussion Pull Request 2162 File Diff Pull Request Description
Jira (HI-115) hiera recursive guard
Title: Message Title
Steve Traylen updated an issue
Hiera / HI-115
hiera recursive guard
Change By:
Steve Traylen
Therecursiveguardisactivatedifthesamevariableisreferencedtwice.Forexample: {code} global.yamla:'%{b}-%{b}' {code} hieraa {code} /usr/lib/ruby/vendor_ruby/hiera/recursive_guard.rb:13:in`check':Detectedin[b](Hiera::InterpolationLoop) {code} Alsotheerrormessageisnotveryinformative.
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-1058) puppet apply loading facts twice
Title: Message Title
Erik Daln commented on an issue
Re: puppet apply loading facts twice
https://github.com/puppetlabs/puppet/pull/2162
Add Comment
Puppet / PUP-1058
puppet apply loading facts twice
given the site.pp with: {code} node default { notice(Busy compiling catalog) } {code} and a module dir setup like: {code} % mkdir modules % puppet module install ripienaar-concat --modulepath=`pwd`/modules {code} I have no config so its all defaults: {code} % puppet apply --configprint config /home/rip/.puppet/puppet.conf % ca...
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-233) Don't reactivate nodes unless a new catalog is submitted.
Title: Message Title redmine.exporter created an issue PuppetDB / PDB-233 Don't reactivate nodes unless a new catalog is submitted. Issue Type: New Feature Assignee: Unassigned Created: 16/Dec/13 8:37 AM Labels: redmine Priority: Normal Reporter: redmine.exporter I recently had an issue with a node that created an exported resource that was missing a parameter (sshkey missing the 'key' value). This caused some errors on hosts collecting that resource (it also broke other sshkey resources, but that's another issue). I deactivated the node in puppetdb and all was well for a while. But this host was having other issues including catalog errors on subsequent runs. So the host was able to submit facts, clearing the deactivated timestamp from puppetdb, but was not able to submit a new catalog to fix the broken resource. Thus my problems started all over again. Would it be possible to not reactivate a deactivated node unless a new catalog is successfully submitted? Does that make sense to do or am I off base in my analysis? Add Comment
Jira (PUP-939) add support for enumerable type(s) in all iterative functions
Title: Message Title Henrik Lindberg assigned an issue to Henrik Lindberg Puppet / PUP-939 add support for enumerable type(s) in all iterative functions Change By: Henrik Lindberg Assignee: HenrikLindberg 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-939) add support for enumerable type(s) in all iterative functions
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-939 add support for enumerable type(s) in all iterative functions Change By: Henrik Lindberg Sprint: Week2013-12-11to2013-12-18 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-939) add support for enumerable type(s) in all iterative functions
Title: Message Title Henrik Lindberg assigned an issue to Henrik Lindberg Puppet / PUP-939 add support for enumerable type(s) in all iterative functions Change By: Henrik Lindberg Assignee: HenrikLindberg 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-868) Deprecate Unusable Certificate Faces
Title: Message Title Andrew Parker commented on an issue Re: Deprecate Unusable Certificate Faces Turns out that certificate is used by people to download the certificates from the master when they still want some communication (such as reports), but are using puppet apply. Add Comment Puppet / PUP-868 Deprecate Unusable Certificate Faces The culprits: * ca * certificate_request * certificate_revocation_list These faces are generally unusable and confusing. We need to deprecate them and make it clear that the user is really just looking for the cert subcommand. 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-868) Deprecate Unusable Certificate Faces
Title: Message Title Andrew Parker updated an issue Puppet / PUP-868 Deprecate Unusable Certificate Faces Change By: Andrew Parker Theculprits:*ca* certificate* certificate_request*certificate_revocation_listThesefacesaregenerallyunusableandconfusing.Weneedtodeprecatethemandmakeitclearthattheuserisreallyjustlookingforthecertsubcommand. 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-1060) enablerepo and disablerepo for yum type
Title: Message Title
redmine.exporter created an issue
Puppet / PUP-1060
enablerepo and disablerepo for yum type
Issue Type:
New Feature
Assignee:
Unassigned
Created:
16/Dec/13 9:45 AM
Labels:
redmine customer
Priority:
Normal
Reporter:
redmine.exporter
it would be nice to be able to enable a disabled repo for the installation on one package.
for example installing facter from EPEL.
something like;
pre package { facter: ensure = installed, enablerepo = [ epel, epel-testing ]; }
/pre
Add Comment
Jira (PUP-1061) Install multiple package within a single call to the package manager
Title: Message Title redmine.exporter created an issue Puppet / PUP-1061 Install multiple package within a single call to the package manager Issue Type: New Feature Assignee: Unassigned Created: 16/Dec/13 9:46 AM Labels: redmine customer Priority: Normal Reporter: redmine.exporter During the configuration applying process the package manager is called for each package installation. It is possible to reduce the number of calls to the package manager by gathering package installation and delayed some package installation. Naturally, this modification should not break the dependency graph. Add Comment
Jira (FACT-150) Facter timeouts reap all subprocesses thus confusing Puppet
Title: Message Title redmine.exporter created an issue Facter / FACT-150 Facter timeouts reap all subprocesses thus confusing Puppet Issue Type: Bug Assignee: Eric Sorenson Created: 16/Dec/13 9:52 AM Labels: redmine Priority: Normal Reporter: redmine.exporter It is no longer possible to have puppet install packages via yum/rpm if the network interface is not bound to an IP address. Our use case requires using puppet in the non-daemon mode and this is possible for us because the system will have all necessary manifests and other necessary files locally. This worked just fine with 0.24.6 on Fedora 10, but began failing upon the upgrade to 0.24.8. See the attachments for failure messages and a code diff that seems to have introduced the regression. If I revert this one change, things work nicely once again. Looks like a very simple fix if it weren't for the ominous looking comment in the code. Add Comment
Jira (PUP-1062) Add virtualenv support to the pip package provider
Title: Message Title
redmine.exporter created an issue
Puppet / PUP-1062
Add virtualenv support to the pip package provider
Issue Type:
New Feature
Assignee:
Unassigned
Created:
16/Dec/13 10:02 AM
Labels:
redmine
Priority:
Normal
Reporter:
redmine.exporter
Now that #6527 is merged into master, it is possible to easily add support for virtualenvs and fully complete #3572.
A `virtualenv` argument could be added to the `package` type in order to instrument `pip` to install the requested package into the given virtualenv directory.
For example:
package { my-python-package: ensure = latest, provider = pip, virtualenv = /path/to/virtualenv }
The content of the virtualenv parameter will be passed directly to the `--environment` parameter of the `pip install` command
Some references:
http://pypi.python.org/pypi/pip(http://pypi.python.org/pypi/pip)
http://www.pip-installer.org/en/latest/index.html#using-pip-with-virtualenv(http://www.pip-installer.org/en/latest/index.html#using-pip-with-virtualenv)
Jira (PUP-1062) Add virtualenv support to the pip package provider
Title: Message Title Jason Antman assigned an issue to Jason Antman Puppet / PUP-1062 Add virtualenv support to the pip package provider 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-397) Manage both 32 and 64-bit windows applications
Title: Message Title Michelle Johansen updated an issue Puppet / PUP-397 Manage both 32 and 64-bit windows applications Change By: Michelle Johansen Sprint: Week2013-12-19to2013-12-28 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-397) Manage both 32 and 64-bit windows applications
Title: Message Title Michelle Johansen updated an issue Puppet / PUP-397 Manage both 32 and 64-bit windows applications Change By: Michelle Johansen Sprint: Week2013-12-19to2013-12-28 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-1063) Add Shinken extra atrributes to Nagios types
Title: Message Title redmine.exporter created an issue Puppet / PUP-1063 Add Shinken extra atrributes to Nagios types Issue Type: New Feature Assignee: Unassigned Created: 16/Dec/13 10:24 AM Labels: redmine Priority: Normal Reporter: redmine.exporter Shinken is a new player in the monitoring solutions, written in python it is a very promising software. Is is compatible with Nagios config, and thus quite easily configurable via Puppet. It also has some specific attributes that are not present in Puppet's Nagios native types. I did a pull request which adds them: https://github.com/puppetlabs/puppet/pull/273(https://github.com/puppetlabs/puppet/pull/273) Add Comment
Jira (PUP-1064) Puppet master fails with 'stack level too deep' error when storeconfigs = true with rails stack 3.1.0
Title: Message Title redmine.exporter created an issue Puppet / PUP-1064 Puppet master fails with 'stack level too deep' error when storeconfigs = true with rails stack 3.1.0 Issue Type: Bug Assignee: Unassigned Created: 16/Dec/13 10:24 AM Labels: redmine customer Priority: Normal Reporter: redmine.exporter Out of nowhere, a known-working Puppet stack build script started to fail. The tell-tale error is 'stack level too deep' which from other historical bug reports always seems related to Ruby directly. After many hours of digging around, I checked for updated gem versions on the system. There was an update to rails 3.1.0 (and activerecord, etc.) which apparently is breaking the Puppet master when working with storeconfigs = true. Disabling storeconfigs immediately works as expected again. When reverting from rails and friends 3.1.0 to 3.0.10, Puppet again works as expected. I don't have any insight into where exactly this is all failing, only the version which is causing the issue and the condition to emulate it. This was only tested again Puppet 2.7.3 using the gem install with both webrick and Apache+Passenger. Attached is a debug output.
Jira (PUP-1065) API call to return list of available environments
Title: Message Title redmine.exporter created an issue Puppet / PUP-1065 API call to return list of available environments Issue Type: New Feature Assignee: Unassigned Created: 16/Dec/13 10:25 AM Labels: redmine Priority: Normal Reporter: redmine.exporter Usage: Would like to make an API call as a validation to an ENC to return a list of valid environments: Story: Bob has an ENC in a web interface and wants to add a node to an environment. He sets the environment setting to testing but has no idea until he runs the ENC if the testing environment exists. Instead he'd like his web interface to query the Puppet master and return a list of valid environments so he can validate that the testing environment exists. Add Comment
Jira (PUP-1066) yum repos should be ensurable.
Title: Message Title redmine.exporter created an issue Puppet / PUP-1066 yum repos should be ensurable. Issue Type: New Feature Assignee: Unassigned Created: 16/Dec/13 10:27 AM Labels: redmine customer Priority: Normal Reporter: redmine.exporter This should be done so that we can solve: #949 - yumrepo should support removal of repository #1023 - yumrepo option to purge unmanaged repos Add Comment This message was sent by
Jira (PUP-1067) Custom Object Variables support for Nagios
Title: Message Title redmine.exporter created an issue Puppet / PUP-1067 Custom Object Variables support for Nagios Issue Type: New Feature Assignee: Unassigned Created: 16/Dec/13 10:29 AM Labels: redmine Priority: Normal Reporter: redmine.exporter With the release of nagios3 custom object variables has been supported but there is no way to use them within puppet, please see http://nagios.sourceforge.net/docs/3_0/customobjectvars.html. Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
Jira (PUP-1051) gem package provider is confused by platform components in version strings
Title: Message Title
Pedro Crte-Real commented on an issue
Re: gem package provider is confused by platform components in version strings
The move to JIRA doesn't seem to have imported the comments. One of the comments has a simple patch to fix this. Could anyone please commit this or tell me what else needs to be done to get this committed?
Add Comment
Puppet / PUP-1051
gem package provider is confused by platform components in version strings
Using: package{'facter': ensure = latest, provider = 'gem', source = http://puppet:8808, } Produces:notice: /Stage[main]/Common_puppet::Hpux/Package[facter]/ensure: ensure changed '1.6.17' to '1.6.17 ruby' This happens on every puppet run.
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 (PUP-1069) Implement feature :upgradeable for OpenBSD package provider
Title: Message Title redmine.exporter created an issue Puppet / PUP-1069 Implement feature :upgradeable for OpenBSD package provider Issue Type: New Feature Assignee: Unassigned Created: 16/Dec/13 10:34 AM Labels: redmine Priority: Normal Reporter: redmine.exporter It's currently not possible to use ensure = latest on OpenBSD. The code itself works correct in my testing, however I'm having some issues with getting spec tests to pass and I'd appreciate some help with that as it appears to return the version for the bash fixture, and not the new (or old) version of tcsh. Add Comment
Jira (FACT-151) Structured data should be supported
Title: Message Title
redmine.exporter created an issue
Facter / FACT-151
Structured data should be supported
Issue Type:
New Feature
Assignee:
Eric Sorenson
Created:
16/Dec/13 10:34 AM
Labels:
redmine
Priority:
Normal
Reporter:
redmine.exporter
Facter currently only supports a flat result list, and it should instead support structured data - basically, a hash of hashes and arrays.
This should probably be able to be represented in two ways - either a hash of hashes/arrays, or namespaces. That is, this: pre {:top = {:middle = {:bottom = value}}} /pre Could also be represented as: pre top::middle::bottom = value /pre
We could optionally have a converter that s/::/_/g for backward compatibility, which should be both trivial and unnecessary, but there should definitely be some kind of backward compatibility mode for callers who can't deal with structured data.
Add Comment
Jira (PUP-1068) Puppet master can't submit reports to an HTTP server using basic auth
Title: Message Title redmine.exporter created an issue Puppet / PUP-1068 Puppet master can't submit reports to an HTTP server using basic auth Issue Type: Bug Assignee: Unassigned Created: 16/Dec/13 10:33 AM Labels: redmine Priority: Normal Reporter: redmine.exporter If you turn on HTTP basic auth in Puppet Dashboard's vhost config, Puppet is unable to communicate with it. Setting a `reporturl` of (for example) http://puppet:puppet@localhost:3000/reports will not cause puppet to authenticate itself to Dashboard. The ENC script doesn't work either; see issue #5126. The approach in Matt and my patch in comment 7 could probably be dropped into lib/reports/http.rb. Add Comment
Jira (PUP-847) Manage security descriptor owner group
Title: Message Title Eric Sorenson updated an issue Puppet / PUP-847 Manage security descriptor owner group Change By: Eric Sorenson Fix Version/s: 3.5.0 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-845) Create a windows provider
Title: Message Title Eric Sorenson updated an issue Puppet / PUP-845 Create a windows provider Change By: Eric Sorenson Fix Version/s: 3.5.0 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-848) Manage security descriptor protected field
Title: Message Title Eric Sorenson updated an issue Puppet / PUP-848 Manage security descriptor protected field Change By: Eric Sorenson Fix Version/s: 3.5.0 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-846) Manage inheritance
Title: Message Title Eric Sorenson updated an issue Puppet / PUP-846 Manage inheritance Change By: Eric Sorenson Fix Version/s: 3.5.0 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-844) Create basic acl type
Title: Message Title Eric Sorenson updated an issue Puppet / PUP-844 Create basic acl type Change By: Eric Sorenson Fix Version/s: 3.5.0 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-854) Publish module to the forge
Title: Message Title Eric Sorenson updated an issue Puppet / PUP-854 Publish module to the forge Change By: Eric Sorenson Fix Version/s: 3.5.0 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-851) Manage propagation
Title: Message Title Eric Sorenson updated an issue Puppet / PUP-851 Manage propagation Change By: Eric Sorenson Fix Version/s: 3.5.0 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-852) Create acl defined type
Title: Message Title Eric Sorenson updated an issue Puppet / PUP-852 Create acl defined type Change By: Eric Sorenson Fix Version/s: 3.5.0 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-781) sun package provider should not run pkginfo -l
Title: Message Title Mike Andrewjeski commented on an issue Re: sun package provider should not run pkginfo -l makes tremendous sense for people running solaris. Add Comment Puppet / PUP-781 sun package provider should not run pkginfo -l On Solaris, `pkginfo -l` is a heavyweight operation. Currently, the sun package provider uses `pkginfo -l` to get a list of all installed packages, which it uses presumably for prefetch functionaltiy, and then uses that information to decide how to manage packages (Install, remove, etc.) Given that many Solaris boxes are older hardware, and that thi... 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-1070) puppetd doesn't always cleanup lockfile properly
Title: Message Title redmine.exporter created an issue Puppet / PUP-1070 puppetd doesn't always cleanup lockfile properly Issue Type: Bug Assignee: Unassigned Created: 16/Dec/13 10:39 AM Labels: redmine customer Priority: Normal Reporter: redmine.exporter ok I had the patch #2661 now running for some weeks and I had nearly no problems anymore. However from time to time (maybe once,twice a week) a random client doesn't remove its lockfile (@/var/lib/puppet/state/puppetdlock@), hence future runs fail. I assume this might still happen due to a uncatched exception (as in #2261), however the problem is a) hard or nearly impossible to reproduce and b) it occurs really by random. The only thing I can see in the logs: pre Nov 30 19:27:41 foobar puppetd[26228]: Finished catalog run in 98.79 seconds Nov 30 20:00:02 foobar puppetd[3000]: Could not retrieve catalog from remote server: Error 502 on SERVER: html^M headtitle502 Bad Gateway/title/head^M body bgcolor=white^M centerh1502 Bad Gateway/h1/center^M hrcenternginx/0.6.39/center^M /body^M /html^M Nov 30 20:00:03 foobar puppetd[3000]: Using cached catalog Nov 30 20:00:03 foobar puppetd[3000]: Could not retrieve catalog; skipping run Nov 30 20:00:04 foobar puppetd[12169]: Run of Puppet configuration client already in progress; skipping Nov 30 20:30:04 foobar puppetd[21230]: Run of Puppet configuration client already in progress; skipping /pre as I run puppetd by cron twice an hour with --splay I assume that the run between 19:30 and 20:00 got delayed till 20:00. At this time (20:00) a puppetmaster restart happens and due to that the 502 occured. This was the run of pid 3000, the next run (pid 12169) failed, this
