Issue #10972 has been updated by Nick Fagerlund.
Nope, this is a duplicate of #5046 (mixing include and Class{'name':} is
parse-order dependent). To answer questions from the original bug report:
1. #5046.
2. Variables are parse-order dependent. Nothing has included the class you're
reaching into for that variable yet, so Puppet hasn't parsed that code, so the
variable has no value. The general way to resolve this is, if a given scope is
reading the value of a variable in a foreign class, it should declare the class
with 'include' first just to be sure. Of course, parameterized classes can play
hell with that. We're solving this for 3.x with automatic parameter lookup via
Hiera when you use 'include.'
3. You're confusing parse order and catalog application order. The chaining ->
arrows create relationships in the catalog, but they don't affect parse order.
4. If you check the agent logs or run with `--test`, you'll probably see the
same error. If you don't, that's a bug!
----------------------------------------
Bug #10972: Classes can be declared with "class {..." and "include ...", and
the order of such matters
https://projects.puppetlabs.com/issues/10972#change-68738
Author: Phil Frost
Status: Accepted
Priority: Normal
Assignee: Nick Lewis
Category: parameterized classes
Target version:
Affected Puppet version: 2.6.2
Keywords:
Branch:
Consider this manifest:
class nagios::plugins {
$check_procs = "CHECK_PROCS"
}
class nagios::monitor::procs {
Class["nagios::plugins"] -> Class["nagios::monitor::procs"]
notify { "this should not be empty: $nagios::plugins::check_procs": }
}
class server {
include 'nagios::plugins'
include 'nagios::monitor::procs'
}
# try removing this line
class { "nagios::monitor::procs": }
include 'server'
If this is evaluated with puppet apply, an error will result:
warning: Scope(Class[Nagios::Monitor::Procs]): Could not look up qualified
variable 'nagios::plugins::check_procs'; class nagios::plugins has not been
evaluated
If it's evaluated with puppet.agent, then no error will result, but
`$nagios::plugins::check_procs` resolves to `undef`, and the message is "this
should not be empty: ".
I arrived at this manifest because I wanted a class I could include on all
nodes that monitored all sorts of local resources (disks, processes, etc). It
looked simply like this:
class nagios::monitor::localresources {
include nagios::monitor::disk
include nagios::monitor::procs
...
}
If I wanted to override the parameters for one of those resources (for example,
raise the thresholds for the total number of processes) on a particular node,
then I would declare one of the specific monitoring classes before
localresources, like so:
node lottsoprocs {
class { "nagios::monitor::procs": warn => 200, }
include nagios::monitor::localresources
}
....but on most nodes I just `include localresources` and use the defaults.
This mostly works, except when it doesn't, as in the first example given. This
brings to mind a number of issues:
1. `class { foo: }` followed by `include foo` works, but the reverse order is
an error. Order shouldn't matter.
2. If order shouldn't matter, then how can `$nagios::plugins::check_procs` be
`undef` sometimes, even though `nagios::plugins` is declared (albeit later)?
3. Obviously order does matter, but shouldn't `Class["nagios::plugins"] ->
Class["nagios::monitor::procs"]` explicitly require the correct order? Why is
that not causing an error, or reordering things so I don't have this problem?
4. Should something that's an error with `puppet apply` not be an error for
`puppet agent`?
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
