On Sun, Dec 15, 2013 at 10:10 PM, Eric Sorenson < [email protected]> wrote:
> Andy Parker wrote: > >> I'd really like some comments on this. At the moment we are thinking of >> getting this in a puppet 3.5 release, but that is contingent on some >> feedback and review of the idea. >> > > FYI all, there hasn't been follow-up on the mailing list but there is a > ton of discussion in the google doc. Please check it out if this is a topic > that interests you. > > https://docs.google.com/a/puppetlabs.com/document/d/1ipnIchBsFmISEKlyS_ > oGXslutnC9m4JJ84zXMgaoqSI/edit > > Thanks for all of the feedback so far. I think most issues have been addressed. The biggest open question is how to deal with sharing configuration information. Pieter points out that making sure that subcommands have a way of getting a reusable view of the configuration is very important. He also points out that allowing any arbitrary puppet settings that might get added to interfere with existing subcommands that were developed before the setting was added could be a problem. <quote Pieter> This seems vague and a little dangerous. Not only does it imply that the same `--vardir` flag could do different things in different subcommands, but it forces subcommand authors to be aware of every potential interaction between every core Puppet option (which may be dynamic from one version to the next). In addition, the subcommand may be invoked too late to alter certain properties (e.g. `runmode`, which affects `modulepath`, which may affect subcommand load order). As an alternative suggestion, is it more reasonable to ask Puppet core to parse out certain "well-known" option names prior to subcommand invocation, document those options well, and handle configuration alteration in Puppet itself? </quote> Jeff pointed out that he'd really like options to be settable from the environment during the discussion about how to make sure that configuration information gets to the subcommands correctly. <quote Jeff> I'd really like configuration information, which is basically what command line options are, to be read from the environment. This isn't to say that the environment is the only place, just that it MUST be supported. This will enable subcommands to work well in stateless environments like Heroku, Docker, etc... This has worked very well for Heroku applications and is specifically called out in documentation on the subject, such as the 12 Factor App http://12factor.net/config </quote> I think that some sort of synthesis of those two concerns/suggestions might get to something that would be a) powerful for configuring, b) robust in the face of future changes to puppet and subcomands, and c) understandable to users of the system where command line args and environment variables just "do the right thing". I'm however having a little trouble with exactly what it might be. Any thoughts? -- > Eric Sorenson - [email protected] - freenode #puppet: eric0 > puppet platform // coffee // techno // bicycles > > -- > 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 [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/puppet-dev/52AE996A.5010902%40puppetlabs.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014, September 23-24 in San Francisco* -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANhgQXtyc99rgwx9d9%2B2N3mTJ13RWjADgyu9rYMwAwgfi9XV7Q%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
