Issue #10972 has been updated by Josh Cooper.

Status changed from Needs Decision to Accepted
Assignee changed from Josh Cooper to Nick Lewis

I think this is related to, even a duplicate of #5517. In particular, see 
[https://projects.puppetlabs.com/issues/5517#note-17](https://projects.puppetlabs.com/issues/5517#note-17)
----------------------------------------
Bug #10972: Classes can be declared with "class {..." and "include ...", and 
the order of such matters
https://projects.puppetlabs.com/issues/10972

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.

Reply via email to