The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #10848

When is "class { foo: }" not equivalent to "include foo"?

Added by Lars Kellogg-Stedman almost 3 years ago. Updated over 1 year ago.

Status:DuplicateStart date:11/15/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:plumbing
Target version:-
Affected Puppet version:2.6.0 Branch:
Keywords:

We've Moved!

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

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

If I have:

modules/
  autofs/
    manifests/
      init.pp
  virtcluster/
    manifests/
      autofs.pp

And in autofs/manifests/init.pp I have:

class autofs {
}

And in virtcluster/manifests/autofs.pp I have:

class virtcluster::autofs {
  include autofs
}

This works as intended. However, if I replace include with a new-style class directive:

class virtcluster::autofs {
  class { autofs: }
}

This fails with a “duplicate definition” error:

Duplicate definition: Class[Virtcluster::Autofs] is already defined; cannot redefined at ...

Is this expected? I thought that class { foo: } was supposed to be equivalent to include foo, but obviously the semantics are different.

I’m using 2.7.6 right now, but I’ve seen this with earlier versions as well.


Related issues

Duplicates Puppet - Bug #5046: Mixed invocation of parameterized classes leads to order ... Needs Decision 01/13/2011
Duplicates Puppet - Bug #2053: Relative namespacing of class/define names results in big... Accepted 03/06/2009

History

#1 Updated by Matthaus Owens almost 3 years ago

  • Status changed from Unreviewed to Rejected

If you replace

class virtcluster::autofs {
  class { autofs: }
}

with

class virtcluster::autofs {
  class { ::autofs: }
}

it works fine. In your example the lookup happens in the following order…

virtcluster::autofs, then ::autofs

Because an autofs class is found at virtcluster::autofs, that is what puppet uses.

In the updated example, lookup starts at ::autofs and as autofs is found there, that is what puppet uses.

Namespace lookups are relative to the current namespace (virtcluster::autofs), so it starts there and works toward top level. Adding leading colons will use absolute namespace lookup rather than relative lookup. This is the way namespaces are looked up during compilation and while counterintuitive, this is the expected behavior.

Also see http://projects.puppetlabs.com/projects/puppet/wiki/Qualification_of_Nested_Classes for more details.

#2 Updated by Matthaus Owens almost 3 years ago

  • Status changed from Rejected to Re-opened

#3 Updated by Matthaus Owens almost 3 years ago

  • Category set to plumbing
  • Status changed from Re-opened to Accepted
  • Affected Puppet version set to 2.6.0

Sorry, I gave you a fix to make your class statement work, but you are correct, the include and class statements should be consistent in their behavior in this regard.

#4 Updated by Lars Kellogg-Stedman almost 3 years ago

So maybe this is a documentation bug? I’ve been through the documentation at http://docs.puppetlabs.com/guides/language_guide.html several times, and there’s nothing there to indicate that including classes via “class {}” is any different from using “include”. Maybe a note in the “Parameterised Classes” section? E.g:

While the class {} syntax with no parameters is largely equivalent to include, name resolution will start in the local scope rather than the local scope. In other words, class { ::foo: } is equivalent to include foo.

#5 Updated by Nigel Kersten over 2 years ago

  • Status changed from Accepted to Needs Decision
  • Assignee set to Anonymous
  • Keywords set to devtriage

I suspect that our changes in behavior for Telly where we’re removing dynamic variable lookup may affect this and make this actually work.

I need developer input on that one though.

#6 Updated by Nigel Kersten over 2 years ago

  • Target version set to 3.x

#7 Updated by Nick Fagerlund about 2 years ago

The OP on this issue is an unholy combination of #2053 (relative class names are teh suck) and #5046 (order-dependence of resource-like class syntax and include).

Those two dragons aside, the docs make the distinction between the syntaxes mostly clear, and the rewritten language guide I’m posting in a few days will make it even more so, with notes about historical context and all that rot. Closing this as a dupe of both #5046 and #2053.

#8 Updated by Nick Fagerlund about 2 years ago

  • Status changed from Needs Decision to Duplicate

#9 Updated by Nick Fagerlund about 2 years ago

  • Keywords deleted (devtriage)

#10 Updated by Andrew Parker almost 2 years ago

  • Target version deleted (3.x)

#11 Updated by Anonymous over 1 year ago

  • Assignee deleted (Anonymous)

Also available in: Atom PDF