Puppet

A notify is a resource that always runs. Where else would it show up in reports?

nowhere – it does no change to target system whatsoever.

that’s fair to me, altough i don’t feel like there should be 2 types of Notify – one that logs as changes and the other that doesn’t.

a background for this change for us is that we use a custom report to nagios which (among other things) checks if given node is marked as “noauto” (this effects in that puppetd on that node is running with noop). this way we’re alerted is any change on the node is pending, but the change is not being applied automatically. we prefer to use it on critical infrastructure to keep a benefit of site-wide settings and doing changes in controlled manner (only senior staff has access to the nodes and can apply the changes by manually reviewing them and running puppetd without noop parameter by hand).

this is basically a reason why we prefer only real changes appear as changes in reports (ie. we use onlyif parameter for Exec extensively to ensure that it’s triggered only when needed). Notify is a only resource i know which works this way.

We just wouldn’t implement this as a resource at all Konrad. There won’t be “two types of notify”.

For some people, notify messages are “real changes”. They instead have facts that control whether a given notify resource is declared, and so notify resource changes are considered as valid as any other resource change in a report.

i don’t quite understand how facts relate to notify, can you give an example? i can imagine some conditional that trigger notify, which should be threated as an exception, but this is where fail() should be used.

if $myfact == "somevalue" {
  notify { "my message": }
}

fail() is a function. It will only appear server-side.

I’m happy to continue this discussion elsewhere Konrad, but I’d really rather not pollute this ticket log any further.

your code doesn’t trigger on myfact change, but rather on logical evaluation of myfact. i can’t still understand how this is a change – it will trigger on every run of the agent if condition is true and not when myfact has changed.

of course this is puppetlabs software, not community one, so i won’t pollute ticket any longer, we’ll just keep a filtering of notifies in our report parser as a permanent solution, not a workaround.

I believe you’re looking at this the wrong way around Konrad.

Currently the only way to notify on the agent side is to use a notify resource. Because it is a resource, and a special one that always “changes” so that the message is visible, it shows up as a change.

I’m saying that the right way forward is to not use a resource to issue notifications on the agent side, precisely because of what you’re complaining about.

I’m not sure what your line about puppetlabs/community is meant to refer to.