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.
On Friday, April 4, 2014 7:55:21 PM UTC-5, Eric Sorenson wrote: > > 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/07167945-0574-4560-a6a2-0e7c729ce117%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
