My dynamic config-file environment broke in 3.5

[Brian Pitts]

Hi,

After I upgraded my puppetmaster to 3.5, my clients can no longer find my modules. I had my modules broken up into three directories

* modules: third-party modules I install via r10k
* lib-modules: library/generic modules I wrote
* app-modules: application/wrapper modules I wrote

I expressed this in puppet.conf with

[master]
    environment = production
    manifest    = $confdir/environments/$environment/manifests/site.pp
    modulepath  = $confdir/environments/$environment/modules:$confdir/environments/$environment/lib-modules:$confdir/environments/$environment/app-modules

However, my puppet runs fail with "Could not find class atop"; that class is in lib-modules. When I check the modulepath on my master I don't get what I expect

$ sudo puppet config print modulepath --section master --environment production
/etc/puppet/environments/production/modules:/etc/puppet/modules:/usr/share/puppet/modules

Based on the documentation I've read [0], I think this is because I named the directory that I stored my dynamic environments in "environments". In 3.5 if puppet sees a directory named "environments" it will use "directory environments" instead of "config-file environments". I.E. the precedence is

static config-file environments → directory environments → dynamic ($environment) config-file environments

This is a surprise, since I did not intentionally set up directory environments and they don't support my modulepath. To me it seems like this behavior unncecessarily breaks existing puppet setups. Why isn't the precedence

static config-file environments → dynamic ($environment) config-file environments→ directory environments ?

Also, shouldn't a warning about this be added to the release notes?

[0] http://docs.puppetlabs.com/puppet/latest/reference/environments_classic.html#interaction-with-directory-environments

[Eric Sorenson]

Hi Brian, thanks for the report -- this was exactly the problem that led us to recall the 3.5.0 release just now.

There is a workaround that is pretty simple, if you're willing to stick with it: just set `environmentpath=/some/nonexistent/dir` in the [master] section of your puppet.conf. This will cause the directory environment code to bypass your /etc/puppet/environments setup and things should be as they were.

You're right that both the precedence logic should change and the release notes should more accurately reflect the situation; we're working on the code for 3.5.1 and have already updated the release notes to have big flashing warnings.

Please give the workaround above a try before you revert back to 3.4.3 -- it's worked in all of the cases we've been able to reproduce here, and looking at your config it *should* work for you too, but if not I'd be super interested to troubleshoot it further.

We're tracking this at https://tickets.puppetlabs.com/browse/PUP-2158 so add yourself as a watcher to that bug to see how things shake out.

--eric0

[Brian Pitts]

Hi Eric,

I'm glad you're taking this and the yumrepo issue (which also bit me) seriously. I've already downgraded to 3.4.3, but I'll try 3.5.1 as soon as it's available.