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:

Bug #6934

non-fatal method for including classes

Added by Chuck Schweizer over 4 years ago. Updated about 4 years ago.

Status:Needs More InformationStart date:03/31/2011
Priority:NormalDue date:
Assignee:Nigel Kersten% Done:


Target version:-
Affected Puppet version: Branch:

We've Moved!

Ticket tracking is now hosted in JIRA:


There are use cases where people wish to attempt to include a given class, but not to fail if it cannot be found.

This functionality was accidentally provided by external node classifiers in 2.6.x and earlier, but has been removed to achieve consistency in class declarations between ENCs and the DSL.

It should be simple to copy the include function and replace errors with a log message instead.

This probably isn’t possible with parameterized classes.


#1 Updated by Ben Hughes over 4 years ago

  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Nigel Kersten

#2 Updated by Nigel Kersten over 4 years ago

  • Subject changed from nonexistent classes specified in external node definitions to non-fatal method for including classes
  • Status changed from Needs Decision to Needs More Information

Chuck I’m going to retitle this bug at the general desire.

One thing I do not wish to compromise on is consistent behavior between declaring classes in the DSL and in an ENC, so we need to stop talking about ENC specifically.

A workaround is to specify such classes in a parameter list, and then attempt to include those with a non-fatal function.

I’m still not convinced that this is a valid use case. It’s difficult to achieve this without significantly compromising consistency across ENCs, include and class {… } parameterized class declarations, and that inconsistency has been a big problem for the user base.

I need to see more detail on use cases in this ticket before we make a decision.

#3 Updated by Chuck Schweizer about 4 years ago

The main use case i had is now solved with puppet 2.6.7 because of Bug fix #5073.

I would still like puppet to not fail if the class does not exist. Mainly because if coded correctly a missing class should not invalidate the puppet manifest the client runs and I would like puppet to be resilient in that way. I do agree that an error should be raised though. So at this point it is just a preference I have for this solution. If it makes more sense for the manifest build to fail and have the client do nothing puppet 2.6.7 allows my environment to continue to work.

#4 Updated by Nigel Kersten about 4 years ago

So I actually implemented this in a function recently

and we could definitely come up with a variant of ‘include’ that failed gracefully, it would basically be something like:

Puppet::Parser::Functions::newfunction(:try_include, :type => :rvalue, :doc => "try include") do |args|
    include_class = Puppet::Parser::Functions.function(:include)
    send(include_class, arg[0])

It however wouldn’t work with parameterized classes…. which is a bit of a problem.

Also available in: Atom PDF