The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Bug #5670

Failing resources should not notify

Added by R.I. Pienaar over 5 years ago. Updated almost 5 years ago.

Status:ClosedStart date:12/24/2010
Priority:HighDue date:
Assignee:-% Done:

0%

Category:-
Target version:2.6.8
Affected Puppet version:2.6.4 Branch:
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com


Description

Given the code:

exec{"/bin/false": notify => Exec["meh"]}

exec{"meh":
    command => "/usr/bin/cowsay 'fail :('",
    require => Exec["/bin/false"],
    logoutput => true
}

I expect the Exec[“meh”] never to happen because the Exec[“/bin/false”] will always fail, in 0.25.x this was the case:

err: //Exec[/bin/false]/returns: change from notrun to 0 failed: /bin/false returned 1 instead of one of [0] at /home/rip/test.pp:1
notice: //Exec[meh]: Dependency exec[/bin/false] has 1 failures
warning: //Exec[meh]: Skipping because of failed dependencies

In 2.6 though the following happens:

err: /Stage[main]//Exec[/bin/false]/returns: change from notrun to 0 failed: /bin/false returned 1 instead of one of [0] at /home/rip/test.pp:1
notice: /Stage[main]//Exec[meh]: Dependency Exec[/bin/false] has failures: true
warning: /Stage[main]//Exec[meh]: Skipping because of failed dependencies
notice: /Stage[main]//Exec[meh]/returns:  _________ 
notice: /Stage[main]//Exec[meh]/returns: < fail :( >
notice: /Stage[main]//Exec[meh]/returns:  --------- 
notice: /Stage[main]//Exec[meh]/returns:         \   ^__^
notice: /Stage[main]//Exec[meh]/returns:          \  (oo)\_______
notice: /Stage[main]//Exec[meh]/returns:             (__)\       )\/\
notice: /Stage[main]//Exec[meh]/returns:                 ||----w |
notice: /Stage[main]//Exec[meh]/returns:                 ||     ||
notice: /Stage[main]//Exec[meh]: Triggered 'refresh' from 1 events

Related issues

Related to Puppet - Bug #5876: Require and Subscribe on the same refreshonly exec doesnt... Needs More Information 01/13/2011
Related to Puppet - Bug #6922: Failing resources in the middle of a chain should not notify Closed 03/31/2011
Duplicates Puppet - Bug #4071: A failed resource still fires subscribed => resources Duplicate 06/24/2010

History

#1 Updated by R.I. Pienaar over 5 years ago

I should add the same seem to happen if I add a notify to the first resource that notifies a refreshonly exec. That notify should also not cause the exec to run.

#2 Updated by Nigel Kersten over 5 years ago

  • Status changed from Unreviewed to Accepted
  • Priority changed from Normal to High

#3 Updated by Nigel Kersten over 5 years ago

  • Target version set to 2.6.5

#4 Updated by Nigel Kersten about 5 years ago

  • Target version changed from 2.6.5 to 2.6.x

#5 Updated by James Turnbull about 5 years ago

  • Target version changed from 2.6.x to 2.6.6

#6 Updated by James Turnbull about 5 years ago

  • Target version changed from 2.6.6 to 2.6.x

#7 Updated by Nick Lewis about 5 years ago

  • Status changed from Accepted to Merged - Pending Release

Merged to 2.6.next in commit:d7a1424fa9b4626a2faa96d4673308ff91e5deb8.

Events are no longer queued if a resource fails.

#8 Updated by Nigel Kersten about 5 years ago

Verified that RI’s original example fails as desired now:


kripke:puppet nbk$ puppet apply -v /tmp/test.pp 
info: Applying configuration version '1301528797'
err: /Stage[main]//Exec[/usr/bin/false]/returns: change from notrun to 0 failed: /usr/bin/false returned 1 instead of one of [0] at /tmp/test.pp:1
notice: /Stage[main]//Exec[meh]: Dependency Exec[/usr/bin/false] has failures: true
warning: /Stage[main]//Exec[meh]: Skipping because of failed dependencies
notice: Finished catalog run in 0.21 seconds
kripke:puppet nbk$ 

#9 Updated by Doug Warner about 5 years ago

This also appears to happen in 0.25.5; I’m not sure if 0.25 is still supported or not, but this would be great to see in that branch.

#10 Updated by Nigel Kersten about 5 years ago

So RI said this wasn’t the case in 0.25.x, and you’re saying it occurs in 0.25.5… there might be a conflict between those two claims?

#11 Updated by Doug Warner about 5 years ago

I’ll try his test case and report back; but I definitely seem something similar (which is how I ended up at this bug).

#12 Updated by Doug Warner about 5 years ago

This simplified test seems to be working fine for me; even if I remove the “require” from the 2nd exec and add a “refreshonly => true” which is closer to what I currently do. If I can nail down the exact problem I’ll report a new bug against 0.25 since it’s significantly different from 2.6.

#13 Updated by Nick Lewis about 5 years ago

  • Status changed from Merged - Pending Release to Duplicate

#14 Updated by R.I. Pienaar about 5 years ago

Status changed from Available In Testing Branch to Duplicate

duplicate of which ticket? Would be nice if we can get some more details in tickets when status changed to statusses that effectively ends the life of a ticket.

#15 Updated by Nick Lewis about 5 years ago

  • Status changed from Duplicate to Merged - Pending Release

Sorry about that, Redmine problem. I added a “duplicated by” relationship to the other ticket and closed it as duplicate since this was the one work was being done on. Redmine helpfully also closed this one as a duplicate.

#16 Updated by Nick Lewis about 5 years ago

Also, the other ticket is #4071.

#17 Updated by James Turnbull about 5 years ago

  • Target version changed from 2.6.x to 2.6.8

#18 Updated by James Turnbull about 5 years ago

  • Status changed from Merged - Pending Release to Closed

Also available in: Atom PDF