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 On Friday, April 4, 2014 11:37:22 AM UTC-7, Brian Pitts wrote: > > 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 > -- You received this message because you are subscribed to the Google Groups "Puppet Users" 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-users/91063735-f008-4873-b1b3-530ca2e727a8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
