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:

Feature #2692

Allow duplicate resource names for a resource with different providers.

Added by Jordan Sissel over 6 years ago. Updated over 6 years ago.

Status:ClosedStart date:10/02/2009
Priority:NormalDue date:
Assignee:-% Done:

0%

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

We've Moved!

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


Description

This was brought up today at puppetcamp during the “packaging sucks” discussion. The specific request below is mainly for supporting multiple package providers providing packages with the same name. It can perhaps be tied to other resource types, but I don’t have use cases in mind for those at this time.

An example problem to be solved follows:

Both ‘yum’ and ‘gem’ providers can install ‘mysql’ as a package. Yum generally gets you the standard mysql client tools, while gem gets you the ruby mysql module.

You cannot currently do this: class foo { package {

"mysql": ensure => present, provider => yum;
"mysql": ensure => present, provider => gem;

} }

You will get a duplicate resource name complaint. Solving this is probably not totally trivial given the above syntax, if permitted, makes unclear what Package[“mysql”] should reference; more on this later.

Solving this with namespacing may be of value: ::. For example, we could:

file { “bar”: require => Package::Gem[“mysql”]; }

There would be an implied relationship that Package::Gem refers to ‘package’ resources with provider ‘gem’. Backwards compatibility to today’s behavior can be achieved by still allowing Package[“foo”], but throwing an error when Package[“foo”] comes under multiple names.

One way to work around this today is to alias one of these packages to another name, but is not an ideal workaround. Aliasing the gem package as ‘gem-mysql’ and then referring to Package[“gem-mysql”] – doesn’t make me feel warm and fuzzy.

Another option is to only use one package provider; instead of aliasing, convert all your gems to rpms, for example, and only use yum. This practice seems pretty common, and only seems to serve to move the ‘alias’ action from the puppet manifest to the package name (name your rpm package ‘gem-mysql’, for example).


Related issues

Duplicates Puppet - Bug #1398: Common package name in two different providers Accepted 07/07/2008

History

#1 Updated by Jordan Sissel over 6 years ago

  • Affected Puppet version changed from 0.25.0 to 0.24.8

#2 Updated by Peter Meier over 6 years ago

1621 is a similar issue, not?

#3 Updated by Jordan Sissel over 6 years ago

  • Status changed from Unreviewed to Closed

Hmm, I think this is probably a subset of the composite keys request (#1621), yeah.

Marking closed.

Also available in: Atom PDF