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

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 https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Bug #18534

Warn when multiple versions of the same module are available in the modulepath

Added by Josh Cooper over 3 years ago. Updated almost 3 years ago.

Status:Needs DecisionStart date:
Priority:NormalDue date:
Assignee:eric sorenson% Done:

0%

Category:-
Target version:-
Affected Puppet version: Branch:
Keywords:

We've Moved!

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


Description

The module tool tries to prevent multiple versions of the same module from being installed. But there are lots of ways that you can end up in that state, such as by installing a module using a specific modulepath (puppet module install —modulepath dirA)

Then if the master is configured to use multiple modulepaths, modulepath=dirA:dirB, you can easily end up with multiple versions of the same module. This can cause unexpected breakage if the version in dirA is incompatible with respect to the one in dirB, especially when the module, e.g. stdlib, is a dependency shared by multiple modules.. See #18525.

One simple thing to assist debugging this situation would be to issue a warning on the master if there are multiple versions of the same module accessible in its modulepath.


Related issues

Related to Puppet Labs Modules - Bug #18525: Using 3.0.x version of stdlib breaks PE Closed
Related to Puppet - Bug #12173: Masters cannot reliably distinguish between multiple vers... Accepted 01/25/2012

History

#1 Updated by Roger Kennedy almost 3 years ago

  • Status changed from Unreviewed to Needs Decision

I have verified that this is true, however the behavior does not surprise me. The semantic of modulepath is the same as PATH in *NIX systems: when looking for a thing, check the PATH in order and use the first thing found.

There is nothing in --debug on master or agent to indicate where in the modulepath a module was found. However, I think the real issue is #12173. If you could reliably distinguish between different versions of modules, having a “first one found wins” model becomes less problematic.

It may still be prudent to enhance withpath to provide a “fully-qualified” path including the modules directory used. This could also be useful debugging environments, as a site with multiple/complex environments is probably using custom modulepaths for the environments.

#2 Updated by Ryan Coleman almost 3 years ago

  • Assignee set to eric sorenson

The Puppet Module Tool does have a list action that will give you information about all the modules it finds in the modulepath(s) configured in puppet.conf and allows you to specify a list of modulepaths that you wish to inspect. While obviously this doesn’t provide pro-active warnings, it is a built in tool that can help an administrator determine what’s installed.

I think this ticket ought to be closed. Passing to eric0 for review.

Also available in: Atom PDF