| I could reproduce this in a local & clean 5.3 environment. Exploring this functionality raised two concerning issues:
- puppet device is loading plugin code from the proxy agent's cache.
- puppet device is using the plugin code before it is downloading the plugins required to do so
On the one hand this makes it actually work, on the other hand it completely evades environment isolation and will cause confusion when used. Charlie&Thomas' fix above avoids the issue of the loaders failure, but does not help with the loadpath issue. Some background loading from the agent's libdir The device.rb#L253 changes the vardir setting, but this does not update the $LOAD_PATH. I've instrumented the code for some debug output:
david@zion:~/git/puppet$ bundle exec puppet device --verbose --trace |
libdir: replacing '' with '/home/david/.puppetlabs/opt/puppet/cache/lib' |
libdir: replacing '/home/david/.puppetlabs/opt/puppet/cache/lib' with '/home/david/.puppetlabs/opt/puppet/cache/lib' |
vardir before configuring: /home/david/.puppetlabs/opt/puppet/cache |
libdir before configuring: /home/david/.puppetlabs/opt/puppet/cache/lib |
$LOAD_PATH.last before configuring: /home/david/.puppetlabs/opt/puppet/cache/lib |
vardir after configuring: /home/david/.puppetlabs/opt/puppet/cache/devices/panos |
libdir after configuring: /home/david/.puppetlabs/opt/puppet/cache/devices/panos/lib |
$LOAD_PATH.last after configuring: /home/david/.puppetlabs/opt/puppet/cache/lib |
Error: Could not run: cannot load such file -- puppet/util/network_device/panos/device
|
This shows how puppet propagates the new vardir value into the computed libdir, without calling the hook for the updated libdir. 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? .h3 initialising device before pluginsync In device.rb#L258 we set up the device instance to be available for facts and providers, but only the configurer in L303 would activate the pluginsync. We can likely fix this by using the PluginHandler from the Configurer to fetch plugins when we need it. In this case, I'd also suggest reviving the -pluginsync option for the facts}, {{resource, and -apply cases, to allow folks to force a pluginsync when needed. Josh Cooper/Henrik Lindberg does this sound like a sensible approach to fixing this? .h2 conclusion I don't think the original --environment issue is worth fixing before we're loading the code from the right location, and are able to bootstrap a new device without relying on the proxy agent's pluginsync. |
