The Puppet Labs Issue Tracker has Moved:

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

Allowed Characters in Identifier Names

I (Nick) was testing identifier names the other day, and here’s Puppet’s current behavior as of 2.6.4. In cursory tests, it looked 0.25.5 accepted and rejected names identically to 2.6.4, but it sometimes yielded different error messages; I didn’t go into as much depth there.

Class names and defined type names:

  • [a-z0-9][A-Za-z0-9_-]* (No unicode nonsense or %@^ etc.)
    • …but if you use any hyphens, you screw up qualified variable access.
  • Can include :: as a namespace separator.
  • Case insensitive, except for the first letter: a class defined as fooBAR can be declared as foobar, and vice-versa.
    • Additionally, the prohibition on beginning with an uppercase letter only applies to the definition; declaration and variable reference (only the module/class part of the variable namespace, not the final segment) can do whatever they wants with case, including capitalizing the first letter.
  • I couldn’t find any difference between class names and defined type names. Did not test custom native resource types.

Module names:

Like class names except for the following:

  • Can’t use the :: namespace separator.
  • CAN start with a capital letter, as long as the eponymous class name does not start with a capital letter. As in, you can call a module DeveloperBootstrap as long as manifests/init.pp defines a class called developerbootstrap or something.


  • [a-zA-Z0-9_]+ (No unicode nonsense or %@^ etc.)
  • i.e. no hyphens, ever.
  • i.e. no restrictions on the first character; any legal character legal in any position.
  • Case sensitive; $foo and $FOO are different variables. (In qualified variable names e.g. $foo::bar, only the final segment is case-sensitive.)

Parameters in parameterized classes and defined types (they act the same):

Unholy hybrid of variables and classes.

  • [a-z0-9][A-Za-z0-9_]* (no hyphens, extra restrictions on first char, and of course no unicode nonsense.)
  • Case sensitive like a variable.


I have not tested these yet. Daniel says here he knows someone who found a case where storeconfigs had a beef with an uppercase tag name, but he doesn’t know whether that’s an issue with the SQL implementation or with Puppet.

Resource names:

Uniqueness requirement aside, I have not found a way to break these yet. For example, notify {"---testnotify_--_åäようこそçaǧdaş©øéü…œœŒæ": } works fine. Let me know if you find one that kills Puppet, because that would be kind of awesome.

Actually, I wonder if there’s a maximum length. Can’t test that at the moment though.


Garrett discovered (issue #12553) that hyphens are NOT allowed in environment names. Further testing revealed that environments act like variables:

  • [a-zA-Z0-9_]+, no exceptions.
  • Case-sensitive (a node w/ environment 0tESTING won’t trigger the puppet master settings in [0testing])


Although the big case statement at the bottom of lib/puppet/network/authstore.rb makes it look like certnames can have @ symbols, they aren’t reliably allowed to get through auth.conf. (see issue #7014.) However, @ signs ARE allowed as long as the certname does not also contain a “.”.

@ weirdness aside, testing reveals that basically anything other than [a-z0-9-_\.] is forbidden, and will fail either when parsing the config file or when trying to get through auth.conf.