The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #2244

pluginsync fails when no source is available

Added by Derek Whayman almost 5 years ago. Updated over 1 year ago.

Status:ClosedStart date:05/12/2009
Priority:HighDue date:
Assignee:Patrick Carlisle% Done:

0%

Category:agent
Target version:3.0.0
Affected Puppet version:0.25.0 Branch:https://github.com/puppetlabs/puppet/pull/439
Keywords:usability

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

When pluginsync is used without any plugin directories on the server side, an exception is raised rather than an empty set being returned.


Related issues

Duplicated by Puppet - Bug #2939: If pluginsync is enabled but no plugins present confusing... Duplicate 12/16/2009
Blocks Puppet - Feature #5521: pluginsync should be defaulted to true Closed 12/12/2010

History

#1 Updated by Derek Whayman almost 5 years ago

h2. Scenario 1

No [plugins] in /etc/puppet/fileserver.conf

debug: No plugins mount given; autocreating with default permissions

On client, no pluginsource in /etc/puppet/puppet.conf

<0> sa_dewha@engpsr0171.etf.barcapetf.com (0 jobs)
 /var/lib/puppet/plugins
  % ls -l
total 0
<0> sa_dewha@engpsr0171.etf.barcapetf.com (0 jobs)
 /var/lib/puppet/plugins
  % sudo puppetd -t --noop --no-factsync --pluginsync --tags sdkljfh
info: Retrieving plugin
err: /File[/var/lib/puppet/plugins]: Failed to retrieve current state of resource: Could not retrieve information from source(s) puppet://engpsr0170.etf.barcapetf.com/plugins
...

h2. Scenario 2

[plugins] in /etc/puppet/fileserver.conf, without path

...
[plugins]
  allow *
...

info: mount[plugins]: allowing * access
<0> sa_dewha@engpsr0171.etf.barcapetf.com (0 jobs)
 /var/lib/puppet/plugins
  % ls -l
total 0
<0> sa_dewha@engpsr0171.etf.barcapetf.com (0 jobs)
 /var/lib/puppet/plugins
  % sudo puppetd -t --noop --no-factsync --pluginsync --tags sdkljfh
info: Retrieving plugin
err: /File[/var/lib/puppet/plugins]: Failed to retrieve current state of resource: Could not retrieve information from source(s) puppet://engpsr0170.etf.barcapetf.com/plugins

h2. Scenario 3

Fall back to using an old-style mount On Master, in /etc/puppet/fileserver.conf:

...
[oldplugins]
  path /var/lib/puppet/plugins
  allow *
...

On Client, In /etc/puppet/puppet.conf

...
[puppetd]
...
    pluginsource = puppet:///oldplugins/

0> sa_dewha@engpsr0171.etf.barcapetf.com (0 jobs)
 /var/lib/puppet/plugins
  % sudo puppetd -t --noop --no-factsync --pluginsync --tags sdkljfh
<1> sa_dewha@engpsr0171.etf.barcapetf.com (0 jobs)
 /var/lib/puppet/plugins
  % ls -l
total 0
<0> sa_dewha@engpsr0171.etf.barcapetf.com (0 jobs)
 /var/lib/puppet/plugins
  % sudo puppetd -t --noop --no-factsync --pluginsync --tags sdkljfh
info: Retrieving plugin
notice: /File[/var/lib/puppet/plugins/puppet]/ensure: created
notice: /File[/var/lib/puppet/plugins/puppet/parser]/ensure: created
notice: /File[/var/lib/puppet/plugins/puppet/parser/functions]/ensure: created
notice: /File[/var/lib/puppet/plugins/puppet/parser/functions/BCutilities.rb]/ensure: defined 'content' as '{md5}3cdb1b3a2c9377f2b06b8a3d1eb99f7d'
notice: /File[/var/lib/puppet/plugins/puppet/parser/functions/allstringvarsdefined.rb]/ensure: defined 'content' as '{md5}57c37a60a75dfca8918596e07ba200dd'
...
notice: /File[/var/lib/puppet/plugins/puppet/provider/sysctl]/ensure: created
notice: /File[/var/lib/puppet/plugins/puppet/provider/sysctl/parsed.rb]/ensure: defined 'content' as '{md5}d2286da60de06702b4f4088aea013271'
...
notice: /File[/var/lib/puppet/plugins/puppet/type/sysctl.rb]/ensure: defined 'content' as '{md5}2dbd57c096f29efa11a4c041af6e41ef'
...
info: Loading downloaded plugin /var/lib/puppet/plugins/puppet/type/sysctl.rb
info: Redefining sysctl in Puppet::Type
...

It doesn’t seem to be successfully loading my type; that’s another ticket.

#2 Updated by Luke Kanies almost 5 years ago

  • Status changed from Unreviewed to Accepted
  • Target version set to 0.25.0

#3 Updated by Luke Kanies almost 5 years ago

  • Subject changed from Non-modular pluginsync fails to pluginsync fails when no source is available
  • Category set to agent
  • Assignee set to Luke Kanies

#4 Updated by Luke Kanies almost 5 years ago

  • Assignee changed from Luke Kanies to Puppet Community
  • Target version changed from 0.25.0 to 2.6.0

For now, I’m going to bump this. It’s just a logging issue, it doesn’t actually hurt anything, and what I would basically say is, don’t enable pluginsync if you don’t have any plugins.

It’s actually a pretty hard problem to solve, because we’re using standard fileserving. We almost need to do a pre-query to see if there are plugins, and only then do the full synchronization.

#5 Updated by James Turnbull almost 5 years ago

  • Assignee deleted (Puppet Community)

#6 Updated by James Turnbull about 4 years ago

  • Target version changed from 2.6.0 to 2.7.x

#7 Updated by Paul Gear almost 4 years ago

FWIW turning off pluginsync on the server doesn’t fix this (at least on my system using 0.25.1 from Debian backports it doesn’t). I guess each client must be updated as well. I decided to just suppress it in my log monitoring tool instead.

#8 Updated by James Turnbull almost 4 years ago

  • Status changed from Accepted to Needs Decision
  • Target version changed from 2.7.x to 49

Should we perhaps change the severity of the warning in the meantime?

#9 Updated by James Turnbull almost 4 years ago

  • Assignee set to Luke Kanies

#10 Updated by Luke Kanies almost 4 years ago

  • Assignee changed from Luke Kanies to James Turnbull

We can’t – it’s the general framework behaving in a general way, and we really can’t suppress it without special-casing a ton of stuff.

I’ve looked into it pretty deeply, and either we use general services or we don’t. I mean, we could spend two days making it so people who have pluginsync enabled but don’t use plugins don’t get any warnings, but… is it so hard to just not use pluginsync until you have plugins?

#11 Updated by James Turnbull almost 4 years ago

  • Target version changed from 49 to 2.7.x

#12 Updated by Jeff McCune almost 4 years ago

For what it’s worth, there is a work around:

In 0.25.4 if any one of your modules simply has an empty “lib” directory, the warning will disappear.

The automatic fileserver “plugins” mount point needs something, even a blank directory, to prevent the warning.

In any of your modules on your modulepath just create a blank lib directory and this will go away.

#13 Updated by James Turnbull over 3 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (James Turnbull)

#14 Updated by Nigel Kersten over 3 years ago

  • Priority changed from Normal to High
  • Keywords set to usability

#15 Updated by Garrett Honeycutt almost 3 years ago

Can we get a decision from Product on this and either fix it or add it to the README and wherever we keep known bugs?

Thank you!

#16 Updated by Patrick Carlisle about 2 years ago

  • Assignee set to Patrick Carlisle
  • Target version changed from 2.7.x to 3.x

#17 Updated by Patrick Carlisle about 2 years ago

  • Status changed from Accepted to In Topic Branch Pending Review
  • Branch set to https://github.com/puppetlabs/puppet/pull/439

#18 Updated by Daniel Pittman about 2 years ago

  • Status changed from In Topic Branch Pending Review to Merged - Pending Release

#19 Updated by Daniel Pittman almost 2 years ago

  • Target version changed from 3.x to 3.0.0

#20 Updated by Matthaus Owens over 1 year ago

  • Status changed from Merged - Pending Release to Closed

Also available in: Atom PDF