[Andy Parker]

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

an...@puppetlabs.com

Freenode: zaphod42

Twitter: @aparker42

Software Developer

Join us at PuppetConf 2014, September 23-24 in San Francisco - http://puppetconf.com

[Spencer Krum]

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

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANhgQXtkcw6k1H54nmwPbiq3GBo_AvevtL_guCCa-DJXnULdgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
Spencer Krum
(619)-980-7820

[Dustin J. Mitchell]

Agreed with Spencer -- this is pretty much exactly what feature flags
were designed for. That the need for such a flag only became obvious
after the release doesn't change that.

I assume this feature flag would default to true in 4.0, with suitable
warnings. That bit of the migration to 4.0 would actually be pretty
easy for users: if there's a conflict, just set $environmentpath to
something else.

Dustin

[Fei Guo]

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).

[Dominic Cleal]

On 06/04/14 15:49, Andy Parker wrote:
> 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.

I prefer this option, it's clean and as Spencer said, other new features
work in the same way.

--
Dominic Cleal
Red Hat Engineering

[Erik Dalén]

Yes, it seems like the best option to me as well. Can add deprecation warning if the feature is turned off in 3.6.

--
Erik Dalén

[Andy Parker]

sigh...yeah that is looking like it might have to be the choice. I was hoping to avoid it and find a way to slot this new functionality in without a feature flag. I wanted to make the migration to the new environments much more seamless than a feature flag so that people could start migrating much earlier. On reflection this might have been a little too ambitions. As we were putting together the changes for 3.6, which included deprecating the existing parts and updating our packages (PUP-1433), it turned out that automatically creating the directory in the packages would cause problems for users upgrading. In fact, I think we came up with the same problem that everyone encountered, but we just didn't put 2 and 2 together.

The code for option 4 that I put together, seems to solve the issue as well, but it does it at the expense of needing to look for the existence of the directories in the modulepath. This sounds worse than I think it might be. Since I changed to order that it searches to be legacy -> directory instead of directory -> legacy (legacy is what we've been calling the existing environment configuration mechanisms), and since I suspect that it is pretty unlikely that a request would be for an environment that has not module directories, then I think it has only added a few (# of entries in the modulepath) extra stat calls per request. Not ideal, but maybe ok?

If I were to implement the feature flag, how should it work? I could make the environmentpath setting the flag and have the default value "", then anything else would turn them on. Once they are on should it be the behavior that showed up in 3.5.0 (directory -> legacy) or should it have directory envs replace legacy envs?

 

--
Dominic Cleal
Red Hat Engineering

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/53426165.7020501%40redhat.com.

For more options, visit https://groups.google.com/d/optout.

[Dustin J. Mitchell]

On Mon, Apr 7, 2014 at 5:17 AM, Andy Parker <an...@puppetlabs.com> wrote:
> Once they are on should it be the behavior that showed up in 3.5.0
> (directory -> legacy) or should it have directory envs replace legacy envs?

Is there functionality implemented by legacy that can't be replicated
by directory (at the cost of rearranging some directories, perhaps)?
From my read, no -- in which case, best to only have one way to
implement envs.

Dustin

[Andy Parker]

3.5.0 should be able to handle manifests and modules completely. It doesn't have config_version implemented. 3.6.0 has everything that the directory environments will support, which ends up making the translation to them pretty simple in most cases.

 

Dustin

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAJtE5vQVZrovWuNsQ%3DWCzsOM0O0xMpS_Owp%2BpzM_FtdK-AXXOA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Per Cederqvist]

On Monday, April 7, 2014 3:03:34 PM UTC+2, Andy Parker wrote:

On Mon, Apr 7, 2014 at 5:53 AM, Dustin J. Mitchell <dus...@v.igoro.us> wrote:

On Mon, Apr 7, 2014 at 5:17 AM, Andy Parker <an...@puppetlabs.com> wrote:
> Once they are on should it be the behavior that showed up in 3.5.0
> (directory -> legacy) or should it have directory envs replace legacy envs?

Is there functionality implemented by legacy that can't be replicated
by directory (at the cost of rearranging some directories, perhaps)?
From my read, no -- in which case, best to only have one way to
implement envs.

3.5.0 should be able to handle manifests and modules completely. It doesn't have config_version implemented. 3.6.0 has everything that the directory environments will support, which ends up making the translation to them pretty simple in most cases.

 

Really? I have three directories in my modulepath:

 - modules: this is were I store generic modules

 - services: this is site-specific modules

 - forge: modules I have downloaded from the Puppet Forge

The services area is an idea I got from <http://projects.puppetlabs.com/projects/1/wiki/Puppet_Best_Practice2>.

It is perhaps not as useful today as it once was, since we have hiera today. But I suspect I am not alone in

having several areas of modules.

Personally, I like having modules I got from external sourced separated from modules I have

written myself. It makes it easier to know what I need to upgrade and what I need to take

full responsibility for myself.

My understanding is that with Directory Environments I'm restricted to a single area.

Given that this breaks with a "Puppet Best Practice" document I think this is a

severe restriction. (I hope I will be able to use multiple areas in the future as well.)

For reference, this is how I set up my modulepath now, after having made changes so

that my setup works with Puppet 3.5.0:

[master]
    modulepath=/etc/puppet/environs/$environment/modules:/etc/puppet/environs/$environment/services:/etc/puppet/environs/$environment/forge
    manifest=/etc/puppet/environs/$environment/manifests/

Yours,

    /ceder 

[Andy Parker]

On Mon, Apr 7, 2014 at 7:12 AM, Per Cederqvist <ce...@lysator.liu.se> wrote:

On Monday, April 7, 2014 3:03:34 PM UTC+2, Andy Parker wrote:

On Mon, Apr 7, 2014 at 5:53 AM, Dustin J. Mitchell <dus...@v.igoro.us> wrote:

On Mon, Apr 7, 2014 at 5:17 AM, Andy Parker <an...@puppetlabs.com> wrote:
> Once they are on should it be the behavior that showed up in 3.5.0
> (directory -> legacy) or should it have directory envs replace legacy envs?

Is there functionality implemented by legacy that can't be replicated
by directory (at the cost of rearranging some directories, perhaps)?
From my read, no -- in which case, best to only have one way to
implement envs.

3.5.0 should be able to handle manifests and modules completely. It doesn't have config_version implemented. 3.6.0 has everything that the directory environments will support, which ends up making the translation to them pretty simple in most cases.

 

Really? I have three directories in my modulepath:

Sorry, I should have been more explicit. 3.5.0 can handle manifests and modules, but not how many people spread them out and also cannot handle config_version. 3.6.0 will be able to handle all of the various ways that modules and manifests get spread out (using environment.conf from PUP-1596) as well as config_version.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/7db42ac7-fcd6-4e77-8ba0-2fbf911a2ac5%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[John Bollinger]

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?

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).


John

[Russell Harrison]

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

[Andy Parker]

On Mon, Apr 7, 2014 at 8:04 AM, John Bollinger <john.bo...@stjude.org> 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 puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/87d78bab-86ca-4972-b1ca-27fd724b0eff%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Andy Parker]

On Tue, Apr 8, 2014 at 2:37 PM, Russell Harrison <fed...@russellharrison.com> 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.

 

--

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.

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.