Ask Your Question

Puppetserver 2.1.1: loading custom types/providers from module

asked 2015-08-15 04:20:46 -0500

badbishop gravatar image

I have a bunch of custom types and providers written and tested against Puppet 2.7.whatever. The said types/providers sit in a dedicated module, which contains only lib subdirectory with all extensions under it. The custom types are tested from another module/class under the same modules subdirectory. As far as I understand, this used to belong to 'best practices'. Now, with Puppetserver 2.1.1 at least two things have changed:

The extensions defined in a different module are not loaded. If the class using custom types is declared in manifest under module 'test', and the custom types/providers are under module '_ext', I get Error: Failed to apply catalog: Parameter name failed on Resources[<my_custom_type>]. The extensions are not even downloaded from the server. As soon as I symlink _ext/lib to 'test/lib', it works. Symlink removed, everything is purged from cache on the next agent run. So, what are the new rules of loading plugins defined in modules? Do I have to tweak auth.conf?

I have several providers for different types, using the same command-line utility. Eventually, I have factored out a few class instance methods into a parent class that inherits from Puppet::Provider and is 'required' and is passed as 'parent' argument to Puppet::Type.type(:<custom_type>).provide function. The require uses the relative path, like in require 'puppet/provider/<parent>.rb' It works with Puppet 2.7 but Puppetserver 2.1.1 throws an excepton:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Evaluation Error: Error while evaluating a Resource Statement, Could not autoload puppet/type/<custom_type>: Could not autoload puppet/provider/<custom_type>/<custom_provider>: no such file to load -- puppet/provider/<parent>

So, what is the best way to include a parent class in this scenario? The full path to class will be different on the server and on the agent, so this is hardly an option.

I have used the default settings on server and minimal agent configuration. pluginsync is set to true on the agent, but that's default anyway.

edit retag flag offensive close merge delete

2 answers

Sort by ยป oldest newest most voted

answered 2015-08-17 10:51:26 -0500

camlow325 gravatar image

The second issue sounds like it might be the same as what is being discussed in SERVER-571. Under Puppet 3.x and earlier (including Puppet Server 1.x), the master and agent shared the same libdir. These were separated under Puppet 4.x (and Puppet Server 2.x). That separation had caused issues when the expectation was that code delivered in a module needed to be pluginsync'ed to the agent's libdir such that it could then be used by the master. The only known workaround for this issue is along the lines of what you had mentioned regarding an adjustment to the ruby-load-path. The following change will likely be made in the default "puppetserver.conf" file for the next Puppet Server 2.x release:

ruby-load-path: [/opt/puppetlabs/puppet/lib/ruby/vendor_ruby, /opt/puppetlabs/puppet/cache/lib]

This is something that hopefully will be worked for a later Puppet release to avoid the continued need to conflate the master and agent libdir values. A placeholder epic for that work is currently at PUP-4885.

edit flag offensive delete link more


Are you sure? The error happens *on the server*, not on the client. How specifying the client's caching directory would help? I've tested it right away, it didn't work.

badbishop gravatar imagebadbishop ( 2015-08-17 11:35:52 -0500 )edit

answered 2015-08-15 15:18:01 -0500

badbishop gravatar image

I guess I can answer the first question. The problem is the module name, _ext. If I just change it to ext, all extensions are loaded.

A dirty fix for the second issue is to add the absolute path to ruby-load-path in puppetserver.conf:

ruby-load-path: [/opt/puppetlabs/puppet/lib/ruby/vendor_ruby, /etc/puppetlabs/code/environments/<myenvironment>/modules/ext/lib]

Does it have to be so ugly?

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2015-08-15 04:20:46 -0500

Seen: 462 times

Last updated: Aug 17 '15