I'd second what Spencer said. We (user experience research and eric0) talked to 8 Puppet users the past week to learn how they use Environments and their opinions on Directory Environments, and every single one is making heavy use of Puppet Environments, in their original words "I won't use Puppet if there is no environments, it's crucial to what we do". Not surprisingly, most of them use dynamic environments, so $environment is something critical too. On that note, option 7 and 8 are definitely no-go. Additionally, when we explained what Directory Environments feature is and how it works, users have very positive reaction to the feature and they believe this is the right path to go.
I think the feature complete directory environments (that you can configure modulepath, manifests, config_version) will solve a lot of the problems and challenges users run into in the just released 3.5 incomplete version of Directory Environments. I'd agree the migration could be challenging to take consideration of all edge cases, although the 8 users we talked to last week have fairly standard use cases (mostly it's just modulepath and manifests being configurable). On Sunday, April 6, 2014 8:13:24 AM UTC-7, Spencer Krum wrote: > > Hi Andy, > > Thanks for compiling this list of options. As a user of Puppet and not a > dev, here are my reactions: I think options 7 and 8 are non-starters, we > need that functionality. Option 9 would be very hard to handle all cases. > Option 3 would cause a debugging nightmare for all of us. I think 4 and 5 > are again going to be very racy. I like directory environments so I don't > like 6 either. > > I think option 2 is the way forward. This is in keeping with the other > experimental features rolled out in the 3.x line. Power users can turn on > directory environments and figure it out, then write blog posts and other > documentation on how to use it for the more causal Puppet users. Directory > environments can join the growing list of things that are optional in 3.x > and will be default in 4.x. I don't particularly hate option 1 but I do > think it would be better to force users to use either the old way or the > new way, not both at the same time. > > Thanks again, > Spencer > > > On Sun, Apr 6, 2014 at 7:49 AM, Andy Parker <an...@puppetlabs.com<javascript:> > > 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 >> a...@puppetlabs.com <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 puppet-dev+...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/CANhgQXtkcw6k1H54nmwPbiq3GBo_AvevtL_guCCa-DJXnULdgg%40mail.gmail.com<https://groups.google.com/d/msgid/puppet-dev/CANhgQXtkcw6k1H54nmwPbiq3GBo_AvevtL_guCCa-DJXnULdgg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Spencer Krum > (619)-980-7820 > -- 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/e5fe9dea-ce1f-4f81-814f-220af47ac6f6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
