Issue #7270 has been updated by Kelsey Hightower.
I have updated my puppet-dashboard-face to use this patch. This should provide an example use case for accessing paramaters from `puppet.conf`. https://github.com/khightower/puppet-dashboard-face One thing I need to figure out is how to address settings via section names. Right now I am prefixing my parameters with `dashboard_face_` even though they are under a different section. I am doing this in `puppet.conf`: [dashboard] dashboard_face_adapter = mysql dashboard_face_host = 127.0.0.1 dashboard_face_database = dashboard_production dashboard_face_username = dashboard dashboard_face_password = dashboard I am using the settings like this: @user = options[:username] || Puppet.settings[:dashboard_face_username] @password = options[:password] || Puppet.settings[:dashboard_face_password] @database = options[:database] || Puppet.settings[:dashboard_face_database] @host = options[:host] || Puppet.settings[:dashboard_face_host] @adapter = options[:adapter] || Puppet.settings[:dashboard_face_adapter] I would like to do this: Puppet.settings["dashboard"][:database] ---------------------------------------- Bug #7270: unify global options with face and action options... https://projects.puppetlabs.com/issues/7270 Author: Daniel Pittman Status: In Topic Branch Pending Merge Priority: Low Assignee: Category: Faces Target version: 2.7.x Affected Puppet version: development Keywords: Branch: https://github.com/khightower/puppet/commits/feature/master/7270 At the moment we handle global options for faces in a ... different way. They are basically the old fashioned application options, kind of vaguely repurposed to do something approximating the right thing. We should unify the behaviour of those, ideally along with options derived from our configuration system, and make them all behave consistently. This would naturally want to involve unification of the DSL for declaring options, and in turn for introspection of them: that would make it practical to have them in the help output, and so forth. Which is desirable, especially round the area of option validation. It also means we can unify error handling, so that we don't have some classes of validation resulting in good help output, and others resulting in bad help output, just because they are handled by different substrates in the product. -- 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 post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
