Jira (PUP-8766) puppet device fails with undefined method `loaders' for nil:NilClass when env is not production

[Josh Cooper (JIRA)]

Title: Message Title

Josh Cooper commented on PUP-8766   Re: puppet device fails with undefined method `loaders' for nil:NilClass when env is not production About the loaders failure. Puppet device should definitely be using Puppet::Node::Environment.remote when requesting a catalog from a remote puppetserver (like agent). We can workaround this by explicitly managing libdir in device.rb, but really this is a dangerous lack of consistency in the underlying settings framework. Josh Cooper, is there a chance of getting this fixed for all? Welcome to the insanity that is puppet settings. If you change the default value of vardir, then any derived settings like libdir will resolve based on the new value of vardir, however, hooks for the derived settings are never called, so you end up with the ruby $LOAD_PATH pointing to the default location: irb(main):001:0> require 'puppet' => true irb(main):002:0> Puppet.initialize_settings => [:debug, :info, :notice, :warning, :err, :alert, :emerg, :crit] irb(main):003:0> Puppet[:vardir] = '/tmp/vardir' => "/tmp/vardir" irb(main):004:0> Puppet[:libdir] => "/tmp/vardir/lib" irb(main):005:0> $LOAD_PATH.grep /cache/ => ["/Users/josh/.puppetlabs/opt/puppet/cache/lib"] Since device is somewhat special (requesting catalogs on behalf of other nodes), I would just have it set :libdir explicitly. Also note that puppet will ensure the $LOAD_PATH is updated to include all of the lib directories from modules in the current environment. If the device application needs to be able to switch environments based on the ENC like the agent does, then we should exclude the device application from there, otherwise device will be able to see modules that it shouldn't. We can likely fix this by using the PluginHandler from the Configurer to fetch plugins when we need it. You should be able to use Puppet::Configurer::PluginHandler to perform a pluginsync. The tricky part is making sure you're sending the right set of facts and that you're resolving the environment correctly (whether it set in the ENC, and whether the device node is allowed to override the ENC's value). If the ENC is authoritative, then its possible you'll receive a catalog compiled in an environment that's different than the environment the device application requested. It's also possible for a fact to cause the environment to change. This is why the Configurer has logic to ask for the {{Node}}s environment, switch environments when requesting the catalog, then checking to see that the catalog's environment is the same as what it requested. If not, it switches again, does another pluginsync, requests another catalog, etc. If it doesn't converge after a few times, it will raise an exception. If the device application is always authoritative, then you can avoid all of that. I would expect puppet device to always perform a pluginsync when applying a device catalog so that the plugins and catalog are consistent. Otherwise you can get into a state where the catalog is trying to manage a new property that the old plugin type/provider doesn't know about, and you'll run into difficult to reproduce bugs. So I don't think reviving the --pluginsync option is a good idea. Add Comment   This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.