The Puppet Labs Issue Tracker has Moved:

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using See the following page for information on filing tickets with JIRA:

Bug #17814

Invalid parameter provider for custom types/providers

Added by Drew Blessing over 3 years ago. Updated over 2 years ago.

Status:Needs More InformationStart date:
Priority:UrgentDue date:
Assignee:-% Done:


Target version:-
Affected Puppet version:3.0.1 Branch:

We've Moved!

Ticket tracking is now hosted in JIRA:

This ticket is now tracked at:


In Puppet 3 I am getting an error on all definitions for custom types. It says “Error 400 on SERVER: Invalid parameter provider…”. Provider should be a given parameter for custom types because otherwise there is no way to specify which provider should be used with it. This is potentially a very major bug. Please let me know how I can help so you’re able to reproduce and fix the issue.


#1 Updated by Josh Cooper over 3 years ago

  • Status changed from Unreviewed to Needs More Information

Hi Drew, can you provide some more information about how to reproduce this? Typically, you define a new type as follows:

Puppet::Type.newtype(:yourtype) do

And puppet automatically creates a provider parameter for your type. Can you provide links to your type, provider and sample manifest that demonstrates the problem, ideally a single resource that can be executed via puppet apply?

#2 Updated by Drew Blessing over 3 years ago

I am using two puppet labs modules – vcsrepo and mysql. Both have custom types and providers. One example is the vcsrepo and the type definition is here

After upgrading to Puppet 3 both complain about the provider parameter when defined similar to the following:

vcsrepo { "/path/to/repo":
  ensure    => present,
  provider => git

The vcsrepo hardly required any changes for 3.0 so that would be a good one to test with. The only issue it complains about is the provider parameter not being allowed. Please let me know if you need any more information. Since this deals with custom types and providers it’s a bit complicated for puppet apply but I could probably put something together if it would expedite things at all.

#3 Updated by Drew Blessing over 3 years ago

Alright, so I spun up a vagrant VM and downloaded the vcsrepo module and added a simple test manifest. It works successfully on a puppet client running 3.0.1 by just using puppet apply. I will need to do some more testing to see what exactly is going on. This could be an environment issue although I’m not sure how just yet. Thanks for checking into this Josh.

#4 Updated by Drew Blessing over 3 years ago

  • Status changed from Needs More Information to Closed

Problem solved.

It was because the puppetmaster hadn’t run and picked up the new plugins. I find it a little odd that the puppetmaster even cares what types/providers are available since it’s the client that cares and did have the plugins. Anyway, this appears to be an environment issue and not a bug.

#5 Updated by Ewoud Kohl van Wijngaarden over 3 years ago

  • Status changed from Closed to Re-opened

This sounds a lot like #13858, but for providers instead of types.

I just ran into this as well (tried both puppet 2.7.20 and 3.0.2). One way to reproduce is as follows: * Set up a puppet master on server A * Make server B a puppet client of server A * Set up another puppet master on server B * Make server C a puppet client of server B * Add a puppet module with custom providers (I used puppet-mysql from puppetlabs) to the modules B serves to C, but is not available in the modules A serves to B.

Now when we try to use the module with providers on C we run in the ‘invalid parameter provider’ error. Installing the module on server A, then syncing server B (so the plugins are synced) will solve the problem for server C.

#6 Updated by Josh Cooper over 3 years ago

  • Status changed from Re-opened to Needs More Information

If you have a puppet master and agent on the same host, they both load code from :libdir, see #18154. This can cause problems like you are describing. Agent B runs, pluginsyncs from Master A, and downloads the code into B’s libdir. Only then can Master B load the code necessary to compile the catalog for Agent C.

Try changing the agent’s :libdir setting on each of these hosts, so that it doesn’t conflict with the master running on the same host? Note don’t change :plugindest due to #18459.

#7 Updated by Andy Shinn about 3 years ago

I was running into this issue when running multiple environments. My default environment for the puppetmaster doesn’t have some new types I am testing in another environment and when testing that environment it is failing. Is this related, and maybe perhaps closely identified with issue #12173?

#8 Updated by Joshua Chaitin-Pollak over 2 years ago

Redmine Issue #17814 has been migrated to JIRA:

Also available in: Atom PDF