The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
Add a new metaparameter to send notifications on failure.
|Affected Puppet version:||0.24.8||Branch:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
I have a resource that I expect to run successfully all the time, and when it’s not I want it to trigger the run of another resource that otherwise wouldn’t run.
Basically inverting the success/failure criteria of a notify =>
What I used to do was have a time check exec, and negated the command, with a notify such that if the command actually failed (ie the time was out of sync by more than a few seconds) it would return success to puppet and that would trigger the notify => of another resource to fix the time.
However, once one starts doing reporting, this is not cool since it means that resource fails on every run on every machine from puppet’s perspective and was really not a nice hack. It also litters the logs.
#1 Updated by Hari Sekhon over 5 years ago
To clarify, I do use ntp, however, sometimes the time may get out of sync and ntpd may not correct it, so having an external check realign the time sorts it out and ntp can take over from there. Basically I’ve used -g with ntp and a trigger to the service to restart and step the time by however much it’s out by (unlike the default which doesn’t work if the time is too far out of sync).
I’ve disabled this behaviour, hoping ntpd will gradually adjust the time… and will see how it goes… but I still think this is a useful feature.
#2 Updated by Anonymous over 5 years ago
- Status changed from Unreviewed to Closed
With regards to your original request, It seems like the “unless” metaparameter for the Exec task (see http://reductivelabs.com/static_files/TypeReference.html#exec ) could be used to correct the time if it is detected wrong. Take a look at that, and if you have a different use case, let me know.
I don’t think we should be negating conditions on the graph per se (potentially confusing for people to visualize), but the idea of running “fix this if this says that” is what unless is there for, and seems to cover the use case. If it doesn’t please re-open this.
#3 Updated by Hari Sekhon over 5 years ago
- Status changed from Closed to Re-opened
The unless param to the exec resource does not quite cover it.
For example, I want to trigger a service restart using the service resource, otherwise how am I supposed to know the correct path to the init script, since init scripts are different on different distros, the service construct could have this information, and I just want to trigger a refresh on it only on failure of an exec.
Having this as a meta parameter would be very useful since one could then have the option of getting other resources to trigger either on success or on failure, whereas at the moment we can only do this on success, which means in the exec example, one would have to ! the command line, littering the logs with failures and ruining reporting.
#5 Updated by Nigel Kersten over 3 years ago
- Subject changed from notify => to trigger another resource only on failure of the current resource to Add a new metaparameter to send notifications on failure.
- Status changed from Needs Decision to Accepted
- Assignee deleted (
- Target version set to 3.x
#6 Updated by Mike Hoskins over 3 years ago
Based on the age of the original report, any word on whether this has already been addressed in the latest 2.7.x releases? If not, are there currently plans for it to be included in the next 2.7.x release?
I have a use case where a colleague is attempting to establish relationships between two classes using unless in a package command and a notify to the subsequent class…and it seems to fail in a way that seems similar to this report. For now we are looking to refactor and do it using run stages or execs with alternate meta parameters, but wondering if this fix would help us.
Thanks for any info!