On Tue, Oct 7, 2014 at 1:48 AM, Felix Frank <felix.fr...@alumni.tu-berlin.de > wrote:
> On 10/07/2014 04:05 AM, Britt Gresham wrote: > > I think we should do 2a because there should be rough parity between > > the configuration files and the command line arguments. We should > > do 2 or 2a because as John says, Puppet should, "Stop getting in my > > way!" > > > > > > I think that option 2a is the safest. Allowing command line and > > configuration files to override an ENC makes the most sense when it > > comes to running down a configuration issue with puppet. Instead of > > going to the ENC to find that it is overriding a local configuration > > change you have a limited number of files to search on a node before > > consulting the ENC itself. > > > > Even if 2a does not get chosen the command line arguments should rule > > over any ENC or configuration file because that is what the user is > > explicitly requesting. > > Sounds like a trend. Thanks for the feedback, guys. > > I took a tentative look at the code. While we can easily find out > whether the :environment setting was specified on the command line, > there is no obvious way to find out whether a value was set in the > configuration files rather than left at its default. > > I do feel that variant 2 would be much more restrictive and confusing > than 2a by now. So I we may have to patch the settings subsystem to > allow for this. > > Am I missing something in the existing tool chain? > > No, I don't think so. The closest test is set_by_cli?(param) https://github.com/puppetlabs/puppet/blob/master/lib/puppet/settings.rb#L799 A similar check that lists the layers a parameter is set in would be fairly simple, and if it is set anywhere other than :application_defaults or :overridden_defaults, it would be coming from config file or commandline (except for :memory, though which is a direct override via Puppet[:foo]=). > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/5433A8DC.9000902%40alumni.tu-berlin.de > . > For more options, visit https://groups.google.com/d/optout. > -- Josh Partlow jpart...@puppetlabs.com Developer, Puppet Labs -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CADxAQ5qOXV0j-AuYdUtJsU_qde6EH0j7HuXjU6yicbVb0OjOXw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
