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

Bug #3118

Default node definition should not be required when ENC returns a node definition.

Added by Markus Roberts almost 5 years ago. Updated about 1 year ago.

Status:RejectedStart date:01/27/2010
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Affected Puppet version:0.24.8 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

This behavior is surprising, but not new.

Given the external node tool:

#!/usr/bin/env ruby
print %q{
---
classes:
  - foo
}
exit 0

And site.pp:

class foo {
    notice "foo"
}

class bar {
    notice "bar"
}

node default {
    include bar
}

The following results are seen:

info: Caching node for host-246-104.pubnet.pdx.edu
notice: Scope(Class[bar]): bar
notice: Scope(Class[foo]): foo
notice: Compiled catalog for host-246-104.pubnet.pdx.edu in 0.01 seconds

The same results are seen with 0.24.8 and 0.25.4rc3.

This appears to break the assumption that default is only applied for nodes that aren’t otherwise defined. The same is seen with an explicit node instead of just default in site.pp

History

#1 Updated by Markus Roberts almost 5 years ago

  • Status changed from Unreviewed to Needs Decision
  • Affected Puppet version changed from 0.25.4rc3 to 0.24.8

#2 Updated by Markus Roberts almost 5 years ago

Initial discussion indicates that some users consider this a bug (default should only apply to otherwise undefined nodes) while others consider it a feature (useful to augment behaviour of all nodes / specific nodes independently of the external node manager) and do not see it as surprising (default is defined with regard to the puppet code, and rightly takes no cognizance of what the node manager does).

#3 Updated by Jeff McCune over 4 years ago

Just to throw my two cents on the pile. I personally think this interaction with the default node classification in site.pp is a feature and not a bug.

Most people I talk with are not surprised by this behavior and have not asked for it to change when using an external node classifier.

#4 Updated by Oliver Hookins about 4 years ago

I may be completely wrong here, but my first foray into using an ENC was initially prevented by not having ANY static node definition present (not even a default node). So technically it is not cumulative, because a definition returned by the ENC by itself is not enough. You need at least a default node definition in the files (even if it is completely empty).

For this reason, I see it as a bug.

#5 Updated by James Turnbull almost 4 years ago

  • Assignee set to Nigel Kersten

#6 Updated by Nigel Kersten almost 4 years ago

  • Subject changed from External node tool definitions appear to be cumulative to Default node definition should not be required when ENC returns a node definition.
  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Nigel Kersten)

I agree with Jeff and Oliver.

People do like this cumulative behavior, but we should also not require a default node definition if the ENC returns a node definition.

#7 Updated by Ben Hughes almost 3 years ago

  • Description updated (diff)
  • Status changed from Accepted to Unreviewed

#8 Updated by Luke Kanies almost 3 years ago

  • Description updated (diff)
  • Status changed from Unreviewed to Accepted

Going back to Nigel’s original assessment that this is a bug.

#9 Updated by Anonymous about 1 year ago

This has been open for a long time and our documentation http://docs.puppetlabs.com/puppet/2.7/reference/lang_node_definitions.html#the-default-node contradicts the actual behavior. I am aware of sites relying on the current behavior (i.e. that the default node is always applied), as Jeff suggested above. I would vote to update docs to match the current behavior and close this ticket. Either way it would be good to resolve it.

#10 Updated by Anonymous about 1 year ago

  • Status changed from Accepted to Rejected

As Alex says, this ticket has been open for a long time. This is behavior that is wanted by some and unwanted by others; however, I don’t see us changing this any time soon.

Also available in: Atom PDF