On Mon, Apr 7, 2014 at 8:04 AM, John Bollinger <[email protected]>wrote: > > On Sunday, April 6, 2014 9:49:55 AM UTC-5, Andy Parker wrote: >> >> If the follow doesn't make sense, I'm sorry. I just got off a plane from >> Seattle to Paris and am still a little sleep deprived. >> >> After release of 3.5.0 it turned out that the new directory environments >> interfered with one of the most common ways of setting up dynamic >> environments. >> Specifically, the original blog post about using "$environment" >> interpolation >> in puppet.conf showed putting the various pieces of the environments in >> /etc/puppet/environments, which is the same location that I chose as the >> default environmentpath. >> >> Since a number of users had put directories inside that directory, and >> these >> directories were supposed to represent environments, they appeared to the >> directory environment implementation to *be* directory environments. >> Unfortunately the directories where only part of the full environment and >> so >> when the directory environment code took over, it produced environment >> configurations within puppet that were incomplete, sometimes in very >> subtle >> ways. >> >> > > What are the key criteria? Is it essential that old-style dynamic > environments *automatically* continue to work as they did in earlier > Puppet releases, for all users? Do directory environments require a base > directory exclusively for their own use (e.g. to support their > enumeration)? Since directory environments are not yet a complete feature, > it it essential to include them in this release at all? > > The answer to all of those questions is "yes". The reason that it needs to be in this release is to uncover any issues that we hadn't noticed, like what just happened :)
> If the answers to the last three questions are all "yes", then I think I > favor a variation on options (1 and 2): give the default environmentpath an > *empty* default value. That effectively disables the feature unless a > nonempty environmentpath is specified in Puppet's configuration. Document > that the directory(-ies) specified by that setting, if any, must be > reserved exclusively for directory environments. > > That solution saves adding an explicit feature flag, yet still controls > the feature in a natural way (that defaults to off for existing > configurations). > > Yep. That is the solution we are going with. PR 2159 ( https://github.com/puppetlabs/puppet/pull/2519) has the changes. > > John > > -- > 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/87d78bab-86ca-4972-b1ca-27fd724b0eff%40googlegroups.com<https://groups.google.com/d/msgid/puppet-dev/87d78bab-86ca-4972-b1ca-27fd724b0eff%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014, September 23-24 in San Francisco - **http://puppetconf.com <http://puppetconf.com/>* -- 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/CANhgQXuCq%3DmxNF8c2NdJspO8ZYdvKBUFPXX4WSuffLT4cBxVLA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
