A (let's say) suppress_inherited_dependency_failures option would affect the logic here: https://github.com/puppetlabs/puppet/blob/5.5.x/lib/puppet/transaction.rb#L285 https://github.com/puppetlabs/puppet/blob/5.5.x/lib/puppet/transaction.rb#L398 When suppress_inherited_dependency_failures is true ...
if a resource has a parent |
if the parent is a class |
if the class has a dependency relationship |
if the dependent is a failed resource (or the dependent is a class containing a failed resource) |
mark the class as failed (and mark the resource as failed) |
report (just once) that we are skipping the containing class of the resource suppress the report that we are skipping the resource |
Use case when enabled: given a failure in a resource that is required by a class, a user would see (one) class failure in the report, and could perform a puppet run without suppress_inherited_dependency_failures to identify the resources in the class that were skipped, if necessary. But since the solution to the dependency failure is to resolve the failure in the dependent resource, that would only be valuable for auditing everything that was skipped: the user's attention should be focused on the failed resource (in the example, File['/impossible/xxx.txt']). |