How to fix Puppet fully-qualified parameter path error

configuration-managementpathpuppetsyntax

I regularly but randomly get the following error message when I run the puppet client on machines (non-daemonized):

err: Could not create : Parameter path failed: File paths must be fully qualified
warning: Not using cache on failed catalog
warning: Configuration could not be instantiated: Parameter path failed: File paths must be fully qualified

It seems moderately clear what it means — that I don't have a fully-qualified path in a parameter. However, it doesn't tell me where I can find this to fix it, or even which parameter is wrong 🙁

(If I use the debug option it consistently works, so it seems like a problem with the caching of the manifests… It would be nice to get rid of this for production use, still)

Note : I cannot make this happen consistently :/

Best Answer

[Answering own question after getting around to prodding at the config for a while]

I've managed to track this down to one of the modules which I have written (of course), but it was due to a use of a variable which didn't work out how I expected.

What happened was:

$variable_dir = "/etc/puppet/bar"

class foo {
  file { $variable_dir:
    ensure => directory
  }
}

define some-define() {
   # Trimmed for brevity
   exec { "some-$name":
     # command, creates, timeout etc here
     require => File[$variable_dir],
   }
}

..which basically caused some confusion with the File[] using a variable. I've replaced these with the explicit value of the variable for now and it all works fine, but it was something of a surprise! I'm assuming that my understanding of scope and when variables can be defined/used is somewhat out of whack with Puppet, so I'm going to learn that a lot better...

It seems to have caused the same behaviour as using non-fully-qualified paths on file strings, by failing to find the variable or not obtaining the value? Quite odd, anyway.

Edit : It's quite possible that the variable wasn't found in scope, and so was empty and definitely not a fully-qualified path. Doesn't explain why this was not consistent, however...

Related Topic