Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
None
-
None
-
Froyo
-
Server Emerald 2015-04-29, Server Emerald 2015-05-13
-
Reviewed
Description
EDIT:
The root cause of this ticket is that in Puppet 4 we intended to separate the master and agents' libdirs completely. For this reason, the default Ruby load path for Puppet Server does not include the agent's libdir, and thus, Puppet Server does not load pluginsynced code. This behavior is highly desirable for the future, but there has been some fair criticism levied that we need to have a better "best practice" for delivering server-side plugins.
For more details see SERVER-973 and PUP-4885. For now, the simplest workaround is to add the agent libdir to Puppet Server's ruby load path, e.g.:
[root@bpbv1uly0m97oa5 ~]# diff -U2 /etc/puppetlabs/puppetserver/conf.d/puppetserver.conf{.orig,}
|
--- /etc/puppetlabs/puppetserver/conf.d/puppetserver.conf.orig 2015-04-27 16:27:26.549092573 -0700
|
+++ /etc/puppetlabs/puppetserver/conf.d/puppetserver.conf 2015-04-27 16:22:41.578085778 -0700
|
@@ -3,5 +3,5 @@
|
# Where the puppet-agent dependency places puppet, facter, etc...
|
# Puppet server expects to load Puppet from this location
|
- ruby-load-path: [/opt/puppetlabs/puppet/lib/ruby/vendor_ruby]
|
+ ruby-load-path: [/opt/puppetlabs/puppet/lib/ruby/vendor_ruby, /opt/puppetlabs/puppet/cache/lib]
|
|
|
# This setting determines where JRuby will look for gems. It is also
|
ORIGINAL DESCRIPTION:
Puppet Server 2.0.0
Hiera 2.0.1
CentOS 7.0
There seems to be an issue with Puppet Server loading hiera backends that are pluginsynced from modules. Take this example of a dummy hiera backend...
|
modules/testmodule/lib/hiera/backend/dummy_backend.rb |
class Hiera
|
module Backend
|
class Dummy_backend
|
def lookup(key, scope, order_override, resolution_type)
|
return "some data"
|
end
|
end
|
end
|
end
|
|
/etc/puppetlabs/code/hiera.yaml |
---
|
:backends:
|
- dummy
|
Puppet agent syncs the plugins on the next run
[root@puppet4 modules]# puppet agent -t
|
Info: Retrieving pluginfacts
|
Info: Retrieving plugin
|
Notice: /File[/opt/puppetlabs/puppet/cache/lib/hiera/backend/dummy_backend.rb]/ensure: defined content as '{md5}d3ec116abcb8c2d1bc9fcb336cfa6248'
|
But, if we try and lookup from the puppet server via an agent run (after a server restart)....
|
modules/testmodule/manifests/init.pp |
class testmodule {
|
$foo=hiera('val', 'not set')
|
notify { $foo: }
|
}
|
[root@puppet4 modules]# puppet agent -t
|
Info: Retrieving pluginfacts
|
Info: Retrieving plugin
|
Info: Caching catalog for puppet4.localdomain
|
Info: Applying configuration version '1429773449'
|
Notice: not set
|
Notice: /Stage[main]/Testmodule/Notify[not set]/message: defined 'message' as 'not set'
|
Notice: Applied catalog in 0.02 seconds
|
And running puppet server foreground reveals
2015-04-23 03:19:04,930 INFO [puppet-server] Puppet hiera(): Cannot load backend dummy: no such file to load -- hiera/backend/dummy_backend
|
But, puppet apply does find it
[root@puppet4 modules]# puppet apply -e 'include testmodule'
|
Notice: Compiled catalog for puppet4.localdomain in environment production in 0.29 seconds
|
Notice: some data
|
Notice: /Stage[main]/Testmodule/Notify[some data]/message: defined 'message' as 'some data'
|
Notice: Applied catalog in 0.02 seconds
|
Hiera itself (possibly a separate ticket/issue) also doesn't find it by default...
[root@puppet4 modules]# hiera foo
|
WARN: 2015-04-23 03:13:35 -0400: Cannot load backend dummy: cannot load such file -- hiera/backend/dummy_backend
|
|
|
[root@puppet4 modules]# RUBYLIB=/opt/puppetlabs/puppet/cache/lib hiera foo
|
some data
|
I haven't tested this with other plugins yet, but there looks to be something awry with loading plugins from puppetserver. Another user also reported the same problems with RHEL 7.1
Attachments
Issue Links
- relates to
-
PUP-4885 Master and Agent should not share libdir
-
- Closed
-
-
-
- Closed
-
-
-
- Needs Information
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- links to