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 #8596

Title and name must be unique within a given resource.

Added by Joe McDonagh almost 5 years ago. Updated over 3 years ago.

Status:ClosedStart date:07/23/2011
Priority:UrgentDue date:
Assignee:Nick Lewis% Done:

0%

Category:RAL
Target version:-
Affected Puppet version:2.6.0 Branch:
Keywords:file path

We've Moved!

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


Description

I discovered today that a catalog will compile if two files have the same path yet different namevars. Not sure if this is on purpose for some reason I can’t think of, or what.


Related issues

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

History

#1 Updated by Luke Kanies almost 5 years ago

  • Category set to RAL
  • Status changed from Unreviewed to Accepted
  • Priority changed from Normal to High

This is definitely critical. What version are you seeing this with?

#2 Updated by Joe McDonagh almost 5 years ago

Sorry, forgot to set it in the ticket, 2.6.7.

#3 Updated by Luke Kanies almost 5 years ago

  • Status changed from Accepted to Needs More Information

Can you clarify this a bit? I just tested duplicate files with every combination of duplication I could think of and I still get failures. What’s your failing code?

#4 Updated by Joe McDonagh almost 5 years ago

Hey Luke, sure. Doing this in a hurry sorry for the diff markers in the pastes

-    # This is temporary until a more elegant solution for users can be written
-    file {
-        "bashrc-jmcdonagh":
-            group   => "web",
-            mode    => "600",
-            owner   => "jmcdonagh",
-            path    => "/home/jmcdonagh/.bashrc",
-            require => User::Devuser["jmcdonagh"],
-            source  => "puppet:///dist/users/bashrc-jmcdonagh";
-        "vimrc-jmcdonagh":
-            group   => "web",
-            mode    => "600",
-            owner   => "jmcdonagh",
-            path    => "/home/jmcdonagh/.vimrc",
-            require => User::Devuser["jmcdonagh"],
-            source  => "puppet:///dist/users/vimrc-jmcdonagh";
-    }

I had been putting off adding a parameter for serving profiles in the devuser define, and got around to it this weekend:

+        if ($ensure == "present" and $dotfiles == "true") {
+            file {
+                "/home/${name}/.bash_profile":
+                    ensure  => "present",
+                    group   => "web",
+                    mode    => "600",
+                    owner   => "${name}",
+                    source  => "puppet:///modules/user/user_profiles/${name}/bash_profile";
+                "/home/${name}/.bashrc":
+                    ensure  => "present",
+                    group   => "web",
+                    mode    => "600",
+                    owner   => "${name}",
+                    source  => "puppet:///modules/user/user_profiles/${name}/bashrc";
+            }
+        }

#5 Updated by Joe McDonagh almost 5 years ago

The vimrc I pasted in by accident, the bashrc is the conflicting one, and the resource in the second past is inside a defined resource, not sure if that matters.

#6 Updated by Stefan Schulte almost 5 years ago

  • Affected Puppet version set to 2.6.0

I was able to reproduce the issue with 2.6.0 and 2.7.2rc1. The error was not reproduceable with 0.25.5

0.25.5

Duplicate definition: File[/tmp/foo] is already defined in file /tmp/test.pp at line 8; cannot redefine

2.6.0

notice: /Stage[main]//File[/tmp/foo]/ensure: create
notice: /Stage[main]//File[same_file]/ensure: removed

sample manifest:

file { '/tmp/foo':
  ensure => file,
}

file { 'same_file':
  path   => '/tmp/foo',
  ensure => absent,
}

#7 Updated by Stefan Schulte almost 5 years ago

FWIW: In my opinion it is not a bug, because the title is what matters (at least that is my understanding).

And reading http://docs.puppetlabs.com/guides/language_guide.html:

[...]
The field before the colon is the resource’s title, which must be unique and can be used to refer
to the resource in other parts of the Puppet configuration
[...]
It’s important to note here that the title alone identifies the resource. Even if the resource seems
to conceptually point to the same entity, it’s the title that matters. The following is possible in Puppet,
but is to be avoided as it can lead to errors once things get sent down to the client.

    file { 'sshdconfig':
      name  => '/usr/local/etc/ssh/sshd_config',
      owner => 'root',
    }

    file { '/usr/local/etc/ssh/sshd_config':
      owner => 'sshd',
    }

#8 Updated by Luke Kanies almost 5 years ago

This is absolutely a bug, and the docs there are wrong.

Both title and name need to be unique within a given resource type.

#9 Updated by Nigel Kersten almost 5 years ago

  • Status changed from Needs More Information to Accepted
  • Target version set to 2.6.x

What Luke said. Chasing down the doc history to work out whether there’s a clear path to why this changed, but this is definitely going to be prioritized to be fixed in both 2.6.x (for the last release) and 2.7.x.

#10 Updated by Nigel Kersten almost 5 years ago

  • Priority changed from High to Urgent

#11 Updated by Nick Lewis almost 5 years ago

  • Assignee set to Nick Lewis

#12 Updated by Nigel Kersten almost 5 years ago

  • Subject changed from File resource should probably use path as a secondary unique key to Title and name must be unique within a given resource.

#13 Updated by Nick Lewis almost 5 years ago

  • Status changed from Accepted to Merged - Pending Release

Merged fix to 2.6.x in commit:0157bf3ee2d53173874e37da9848b2753d428a25.

The introduction of composite namevars caused the resource title used in
resource aliases to be set as an array, even when the resource only had one
namevar. This would fail to conflict with non-alias entries in the resource
table, which used a string for the title, even though the single element array
contained the same string.

Now, we flatten the key used in the resource table, so that single element
arrays are represented as strings, and will properly conflict with resource
titles.

Also merged to 2.7.x in commit:8baa4897e777f9515dc1663317f432ace3067bae and master in commit:b13427b56d8529731d0334d420b24a592ecb43ea.

#14 Updated by Nick Fagerlund almost 5 years ago

And I’ve fixed the documentation by… deleting a paragraph from the language guide.

#15 Updated by Michael Stahnke over 4 years ago

  • Status changed from Merged - Pending Release to Closed

Shipped as part of 2.7.3rc1

#16 Updated by James Turnbull over 4 years ago

  • Target version changed from 2.6.x to 2.7.3

#17 Updated by Nigel Kersten over 4 years ago

  • Target version changed from 2.7.3 to 2.6.x

This actually went to 2.6.x

#18 Updated by James Turnbull over 4 years ago

  • Target version changed from 2.6.x to 2.6.10

#19 Updated by Matthaus Owens over 4 years ago

released in 2.6.13rc1

#20 Updated by Matthaus Owens over 4 years ago

  • Target version changed from 2.6.10 to 2.6.13

#21 Updated by Guido Gúnther over 3 years ago

  • Target version changed from 2.6.13 to 2.7.x

This change breaks use cases like:

package { ‘foo’:

ensure => latest,
provider => 'apt',

}

package { ‘foobar’:

name => 'foo',
provider => 'otherprovider',

}

This allows one to have two packages named ‘foo’ on the system. One provided by apt (under /) as well as another one installed by ‘otherprovider’ into an alternative location. Unfortuantely several packaging systems are quite common (e.g. openpkg). A solution would be to also honor more attributes to decide if a resource is unique.

#22 Updated by Anonymous over 3 years ago

  • Target version deleted (2.7.x)

Also available in: Atom PDF