Bug #3561

Error loading provider during pluginsync (provider are downloaded before type)

Added by Frederik Wagner about 2 years ago. Updated 11 months ago.

Status:Duplicate Start date:04/15/2010
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:server
Target version:-
Affected Puppet version:0.25.4 Branch:
Keywords:
Votes: 10

Description

Apparently during the pluginsync providers are downloaded before their corresponding types, therefore the puppet client complains undefined methodprovide' for nil:NilClass` since the type is not yet known during the download of the provider.

After downloading is finished the custom type/provider work fine in this run of puppet.

It look like the plugins are synced in alphabetical order.

puppetd.out - puppet client debug output (14.6 kB) Frederik Wagner, 04/15/2010 08:23 am

puppetmasterd.out - puppetmaster client debug output (6.7 kB) Frederik Wagner, 04/15/2010 08:23 am

Related issues

related to Puppet - Feature #6907: Ensure providers can be used in the same puppet run that ... Closed 03/30/2011
duplicated by Puppet - Feature #4416: Resources cannot be used on the run where they are synced Closed 07/30/2010
duplicates Puppet - Bug #3136: custom plugins "type/" is not loaded first . If provider/... Duplicate 02/01/2010

History

#1
Updated by James Turnbull about 2 years ago

  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Luke Kanies

I don’t think this is the behaviour … Luke?

#2
Updated by Luke Kanies about 2 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Luke Kanies)
  • Target version set to 2.7.x

The load order isn’t actually determined by Puppet – I think it’s essentially determined by how we recurse via globbing.

We’ve done some hackery in the past to make some things like this work, but it’s a hard problem to make sure the type.rb ends up on disk before the provider.rb file, or at least to make sure the provider isn’t loaded.

We probably need some special-casing code in there to not load providers automatically, since they’re so dependent on the type.

#3
Updated by Matt Wise almost 2 years ago

I ran into this exact same problem with the Sysctl module. The fix was renaming the ‘provider’ directory in the module to ‘zprovider’. This is a stupid fix, but it at least temporarily solves the issue. Would like to see a real fix in Puppet to help specify the order of plugins that are synced and loaded.

#4
Updated by Byron Appelt almost 2 years ago

Does the ‘zprovider’ workaround really work? If I rename the directory puppet syncs it just fine, but I don’t think it gets loaded since the custom type will not work.

#5
Updated by Jonathan Booth over 1 year ago

It was working for me back in 0.24.8 or so. I don’t know about in 0.25 or 2.6.

#6
Updated by Dan Carley over 1 year ago

Byron Appelt wrote:

Does the ‘zprovider’ workaround really work? If I rename the directory puppet syncs it just fine, but I don’t think it gets loaded since the custom type will not work.

You’ll need a require line at the bottom of your type to ensure that the provider gets loaded from the new location. Tested on 0.25.5:

require 'puppet/zprovider/NAME`

#7
Updated by Nick Lewis 12 months ago

  • Status changed from Accepted to Duplicate

This seems to be fixed by #4416. Please re-open if that’s not the case.

#8
Updated by James Turnbull 11 months ago

  • Target version deleted (2.7.x)

Also available in: Atom PDF