Puppet

This bug was introduced in commit cc09c1af. Using File.split on a filename ending with a slash drops this ending slash. A resource name ending with a slash gets silently “renamed” and this breaks the dependencies.

I’m closing this as a dupe of #1042, since they really are the same problem.

This is actually a pretty hard problem to fix, and a very easy problem to work around, so I don’t think it qualifies as High priority.

Sorry for reopening this bug. I would like to draw attention to this thread: http://groups.google.com/group/puppet-dev/browse_thread/thread/d36450a5747be593/25d9edad436dbe51?lnk=gst&q=2675

Maybe the solution is just that people fix their manifests with file resources ending with a slash. In this case this issue indeed is a duplicate of #1042. If not, it deserves to stay open as a reminder.

Branch at http://github.com/MarkusQ/puppet/tree/ticket/master/2675

No one (including me) was thrilled with the rush patch intended for 0.25.1, so I’ve got another, more general/cleaner solution in the queue (coming soen).

I just updated (rebased) the branch & ported the key potentially conflicting change (m flag on the regexp) from #2770 to simplify the eventual merge conflict.

This doesn’t apply to 0.25.x cleanly.

Doh, my bad. Try the rebased one.

http://github.com/MarkusQ/puppet/tree/ticket/0.25.x/2675

Pushed in commit:ca56aa7e5849a5489e8d38e29b25ea934caafcd7 in branch 0.25.x

I just tried to update my puppetmaster to 0.25.2rc2, and another variant of this bug resurfaced. Now every client, even those < 0.25, fail with this error:

info: Retrieving plugins
info: Retrieving facts
err: Could not retrieve catalog: Could not find resource File[/etc/pki/] when converting to resource resources on node host.example.com
[...]

The resource triggering the error is quite simple:

file { ["/etc/pki/", "/etc/pki/rpm-gpg/"]:
  ensure => directory,
}

Rewriting it like this solves the problem:

file { ["/etc/pki", "/etc/pki/rpm-gpg"]:
  ensure => directory,
}

As I have dozens of resources ending with a slash, my initial question was: should people edit every “file” resource ending with a slash and stripping it off ? Or should puppet treat File[“/etc/pki”] and File[“/etc/pki/”] as the same ?

Using the 3 demo files described in the inital report can be used to reproduce the error:

$ puppet test1.pp 
notice: //File[/tmp/dir1]/ensure: created
notice: //File[/tmp/dir1/file1]/ensure: created

$ puppet test2.pp 
Could not find resource File[/tmp/dir2/] when converting to resource resources on node host.example.com

$ puppet test3.pp 
Could not find resource File[/tmp/dir3/] when converting to resource resources on node host.example.com

There was an intermittent bug in Puppet::Parser::Resource::Reference,
during initialization, and object could sometimes have its title set
before its type is set. This prevented the title from going through
type-specific canonicalization.

Marc – can you confirm so we can merge and release please! Thanks!

This was also biting us as a test indeterminacy.

Pushed in commit:13cbf043c6e16c14b0ab9fccd5738a8c9e5925b3 in branch 0.25.x

A trailing slash in a File resource is still being stripped off. I found a working workaround to be to not strip off the trailing slash.

http://git.ogd.nl/people?p=jeroenm2/public_git/puppet.git;a=commitdiff;h=524e85160c275effaf8a5550dbb0c22a0fa1e651 (or remote http://git.ogd.nl/~jeroenm2/puppet.git, branch ‘tickets/2675’

I’m unclear on what that patch is supposed to accomplish; it appears that it would simply reintroduce the bug, by making “/some/path/” and “/some/path” be internally distinct when they are not supposed to be.

Bumping this and discussion – my inclination is to what for feedback before closing though.

Mysteriously (or not so mysteriously) upgrading both the server and the client to the 0.25.2 release solved all my problems. It seems I was under the mistaken impression that trailing slashes could no longer be used -as that was what I thought my error messages indicated not finding resource dependencies anymore- I now understand how that would not have made any sense. Apologies to all!