Could you please elaborate a bit more on what is ment by "enumerate environments" in option 6? From my experience it isn't clear what problem this new feature is solving and I'd love to hear (be linked to?) some more background. I found the existing functionality intuitive and extremely easy to implement and understand. This new functionality seems more "auto magical" and I'm not clear on how I'd properly define my module path using it.
Thanks, Russell On Sunday, April 6, 2014 10:49:55 AM UTC-4, 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. > > I've tried to come up with various ways that could resolve the collision of > directory environments and dynamic environemnts: > > 1 Change the default environmentpath to something else > - PRO: This reduces the chance for collision. It can reduce it to near > zero > if we change the default environmentpath to something that is highly > unlikely to be used (/etc/puppet/asdf for example) > - CON: The chance isn't completely gone and it leaves us with a > less-than-ideal default when these are enabled by default (unless we > change the default when other environment options are removed) > 2 Put directory environments behind a feature flag (disabled by default) > - PRO: completely removes the possibility of unwanted collisions > - CON: users will have to take extra action to use the new system. PE > will > have to ensure that they are enabled and the migration is done. > 3 Add heuristics for when a directory that is encountered in the > environmentpath truely constitutes a "directory environment" > - PRO: the directory environments are enabled by default, they won't > (depending on heuristics chosen) interfere with existing > configurations > - CON: using heuristics would remove some valid directory environment > configurations. Heuristics would also fail at times and cause the > diagnosis of the problem to become more complicated. > 4 Make directory environments lower priority than $environment-style > dynamic > environments > - PRO: this would completely preserve backwards compatibility > - CON: The problem is with the definition of a dynamic environments. > The > individual directories of the modulepath don't have to exist, the > manifest directory doesn't have to exist (when an ENC is in use). The > determination could be made by checking if none of the modulepath > directories, nor the manifest exists. That approach might cause a > large > number of stat calls. > 5 Make directory environments inactive with "$environment-style" > environments in use. If $environment shows up in modulepath, manifest, > manifestdir, config_version, or templatedir then skip any use of > directory > environments. > - PRO: automatically does what is needed. Would make directory > environments > inactive for users who are seeing problems. > - CON: Doesn't help if users have a $confdir/environments directory > that > contains subdirectories for whatever reason (i.e. they used to use > dynamic environments and no longer do). Those users would see the > environments suddenly appear. This is also a hidden toggle. If there > is > an issue, it might not be immediately clear what is happening. > Another > issue with this approach is that there is no middle ground between > directory environments and dynamic environments, which may make > migrations more difficult. In a default configuration this stops the > "infinite" environments from appearing, it also stops the default > environment from being available. > 6 Remove directory environments > - PRO: takes us back to the same behavior as has existed for several > years > thereby maintaining existing installations. > - CON: Removes the ability to "enumerate environments", which is the > feature that the directory environments were created to solve. > 7 Remove $environment interpolation > - PRO: This leaves only explicit environment stanzas and directory > environments, therefore no more conflicts. > - CON: completely backwards incompatible. Given that the 3.5.0 > implementation of directory environments is incomplete there isn't > even a > migration for existing dynamic environment users. > 8 Remove environments > - PRO: removes any kind of conflict that could happen. Simplifies the > internals of puppet considerably and resolves all environment related > bugs (such as things leaking between environments). > - CON: completely backwards incompatible. Would cause a lynch mob to > hunt > me down. > 9 Create a migration script > - PRO: Would provide a way of resolving the problem and would put in > place > a better way of changing over. > - CON: many setups cannot be expressed in what is available in 3.5.0. > All > environments could be made to work, but the workflow and for users > would > have to change after they migrate. > > There is a possible problem with option 4. To make directory environments > a lower > priority, there has to be some way of determining if the legacy environment > really exists. This is takes it into the relm of option 3. For instance, > if a > legacy environment is defined to not exist if none of the directories in > its > modulepath exist, then almot all setups will completely shadow directory > environments. This does allow the new directory environments to live side > by > side with dynamic environments, but not with a non-environment setup > (there is > no longer a way of having a static modulepath + directory environments, > since > the modulepath will always exist and therefore the directory environment > will > never be used). > > The implementation that I have for option 4 is at > https://github.com/zaphod42/puppet/tree/issue/stable/dir-envs-collide-with-dyn-envs > > I also attempted (and discarded) an implementation of option 5. Once I was > scanning uninterpolated setting values for "$environment" and that wasn't > fully > working I could tell that the implementation was leading to a bad > place(tm). > > -- > Andrew Parker > [email protected] <javascript:> > 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/9981bd5d-3282-469f-a40d-16bc5b097d5f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
