Puppet

Thanks for the bug report Felix.

Is this also the case for the before, require, subscribe, notify meta-parameters?

Hi Jesse, excellent question.

define my_notify() { notify { $name: }}
define my_exec() { exec { $name: refreshonly => true } }

schedule { "not-ever": period => "never" }

notify { "me-first": }

exec { [ "notify-me", "notify-me-wrapped" ]:
    command => "/bin/echo foo",
    refreshonly => true;
}

class schedule_test {
    notify { "not supposed": schedule => "not-ever" }
    my_notify { "not supposed either": schedule => "not-ever" }
}

class loglevel_test {
    notify { "invisible": loglevel => "debug" }
    my_notify { "invisible too": loglevel => "debug" }
}
class before_test {
    notify { "me-firster": before => Notify["me-first"] }
    my_notify { "me-firstes": before => Notify["me-first"] }
}

class require_test {
    notify { "me-later": require => Notify["me-first"] }
    my_notify { "me-latest": require => Notify["me-first"] }
}

class subscribe_test {
    exec { "/bin/echo i shall run":
            subscribe => Notify["me-first"];
    }
    my_exec {
        "/bin/echo i shall run too":
            subscribe => Notify["me-first"];
    }
}

class notify_test {
    notify { "i cause a run": notify => Exec["notify-me"] }
    my_notify { "i cause a run too": notify => Exec["notify-me-wrapped"] }
}

include schedule_test
include loglevel_test
include before_test
include require_test
include subscribe_test
include notify_test

Require and before appear to work perfectly well.

As for notify and subscribe, well:

puppet apply test.pp | egrep Trigger\|executed
notice: /Stage[main]//Exec[notify-me-wrapped]: Triggered 'refresh' from 1 events
notice: /Stage[main]//Exec[notify-me]: Triggered 'refresh' from 1 events
notice: /Stage[main]/Subscribe_test/My_exec[/bin/echo i shall run too]/Exec[/bin/echo i shall run too]: Triggered 'refresh' from 1 events
notice: /Stage[main]/Subscribe_test/Exec[/bin/echo i shall run]/returns: executed successfully
notice: /Stage[main]/Subscribe_test/Exec[/bin/echo i shall run]: Triggered 'refresh' from 1 events

Note how everything is triggered, but the only exec that actually runs is the one that isn’t wrapped and subscribes.

However, this is consistent with 0.25.5 behaviour:

puppet test.pp  | egrep Trigger\|executed
notice: //subscribe_test/Exec[/bin/echo i shall run]/returns: executed successfully
notice: //subscribe_test/Exec[/bin/echo i shall run]: Triggering 'refresh' from 1 dependencies
notice: //subscribe_test/My_exec[/bin/echo i shall run too]/Exec[/bin/echo i shall run too]: Triggering 'refresh' from 1 dependencies
notice: //Exec[notify-me-wrapped]: Triggering 'refresh' from 1 dependencies
notice: //Exec[notify-me]: Triggering 'refresh' from 1 dependencies

Summarizing:

• before and require are unaffected

• notify and subscribe seem to have been broken for a while, and possibly more severely? [unless I’m misreading this]

• loglevel and schedule are afflicted by a regression

On a sidenote, I tried and bisected this, but the git history is apparently horrible – 90% of the checkouts wouldn’t work for one reason or another, so I gave up.

Erm…s/Jesse/Jeff/.

God, I suck at this =]

Turns out this is documented behaviour. The Language Guide states:

Any metaparameters used when a defined resource is declared are also made available in the definition as variables

I think this needs a design decision then, because frankly, I consider this insane. Who would not want this to work out of the box?

Myself, I’d have to add this variable voodoo to pretty much each and every one of my defined types.

This came up on the mailing list again today, causing me to rethink the issue. This is what I came up with:

Basically, if you want your defined type to behave like classes wrt. meta parameters, you need to add them to each resource in your defined type like this:

  define aaaa () {
    file { '/etc/slapd.d/define':
      ensure  => file,
      content => 'define',
      require => $require,
      before  => $before,
      notify  => $notify,
      ...
    }
  }

It’s highly impractical, but on the other hand, if puppet were to include these automatically, this would raise other questions such as

• what if I want a specific resource to not respect the global require

• how are additional metaparameters of inner resources treated

etc.

Worst thing is, I guess, that changing how this works will break existing manifests, so I think we’ll have to learn to deal.