The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
Custom module functions do not seem to stay within their Environment
|Affected Puppet version:||2.7.22||Branch:|
|Keywords:||function environment scope|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
I have two environments – production, and test In both environments, there exists a module, ‘foo’ Each ‘foo’ module has a lib/puppet/parser/bar.rb defining a custom function, bar() However, the function is different in the two environments (as we’re doing development work).
It seems that only one of the versions of bar() gets loaded, and is then used for BOTH environments.
In our case, the production bar() is being used for evaluating manifests in the test environment as well as in the production environment. This, naturally, messes up the testing process somewhat.
The correct environment version of the module templates, files and manifests is being used for the compilation; it is just the module’s lib/ functions which are not guaranteed to be active. So far, it seems to always use production in preference to the environment asked for.
It also seems that often we have to restart httpd for the function changes to be picked up (we’re running with passenger so this is sort of expected) which is Bug1761 I think.
Finally, for report functions, it seems that they need to be in /var/lib/puppet/lib for them to work; IE we need to have run a ‘puppet agent -t —noop —env=test’ first to pick them up. I can sort of understand this; however /var/lib/puppet/lib doesn’t seem to be getting referenced when compiling a manifest.
This is running puppet 2.7.22
#1 Updated by Josh Cooper almost 3 years ago
- Status changed from Unreviewed to Duplicate
This is a duplicate of #12173. Puppet employs various hacks to try to make this work
Puppet::Util::Autoload, but it doesn’t actually work reliably, e.g. http://projects.puppetlabs.com/issues/4248#note-29.
About the second point, it sounds related to #18461 — currently, a master and agent on the same host, both load code from the pluginsync directory. This can lead to bizarre behavior where the master’s compilation process depends on what code the agent has pluginsynced, and can result in code leaking across environments.