On Tue, Apr 8, 2014 at 2:37 PM, Russell Harrison <[email protected] > wrote:
> 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. > https://tickets.puppetlabs.com/browse/PUP-536 The automagical aspects of it are very similar to how modules are structured. In 3.6.0 the strict layout that is required in 3.5 will be the defaults, but configurable. I think it will end up being much easier to understand, and more flexible, than the existing system. > > 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] >> 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<https://groups.google.com/d/msgid/puppet-dev/9981bd5d-3282-469f-a40d-16bc5b097d5f%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/CANhgQXubuaD-ZXteawgGSgvD_xEc3qVfL02ywB53MNid2yGnwg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
