lib/sous_vide/event_methods.rb
# Called when a resource action has been completed.
Called when a resource action has been completed.
Called when a resource action has been completed .
def resource_completed(new_resource)
      return false if @processing_now.nil? || nested?(new_resource) 
      debug("Received :resource_completed on {@processing_now}")
      @processing_now.duration_ms = (new_resource.elapsed_time.to_f * 1000).to_i
       When this event was fired in why_run mode we override it's status to `why-run`.
       This is also how Chef::Runnerfocred_why_run is implemented so it should be reliable.
       TODO: what happens when :why_run for notification fails?
      if ::Chef::Config[:why_run]
        debug("Resource {@processing_now.name}{@processing_now.action} marked why-run",
              "because Chef::Config[:why_run] is true.")
        @processing_now.status = "why-run"
      end
       This resource was not notified by another and is a subject of normal ordered converge
       process. @resource_collection_cursor is pointing to next resource according to the
       expanded resource collection.
       When chef-client fails we will take remaining entries and add to the report as
       'unprocessed'. It works because resources are ordered and we can keep track where we are.
       why-run mode and notifications are not in natural order and must not move the cursor.
       Having it pointing ahead is relevant because current resource has just been converged
       (maybe 'failed') and it is not 'unprocessed'.
      if !@processing_now.notifying_resource &&  not notified
         !::Chef::Config[:why_run] &&            not why-run
         @run_phase == "converge"                only converge phase
        @resource_collection_cursor += 1
      end
      @processing_now.completed_at = Time.now.strftime("%F %T")
      @processed << @processing_now
      @processing_now = nil
      true
    end
def resource_completed ( new_resource ) return false if @processing_now . nil? || nested? ( new_resource ) debug ( "Received :resource_completed on #{@processing_now}" ) @processing_now . duration_ms = ( new_resource . elapsed_time . to_f * 1000 ) . to_i if :: Chef :: Config [ :why_run ] debug ( "Resource #{@processing_now.name}##{@processing_now.action} marked why-run" , "because Chef::Config[:why_run] is true." ) @processing_now . status = "why-run" end if ! @processing_now . notifying_resource && ! :: Chef :: Config [ :why_run ] && @run_phase == "converge" @resource_collection_cursor += 1 end @processing_now . completed_at = Time . now . strftime ( "%F %T" ) @processed << @processing_now @processing_now = nil true end
Called when a resource action has been completed.
Called when a resource action has been completed .
# ignore nested resources # If a resource has notifications Chef will converge it in a forced_why_run mode to # determine if any update will happen and if the notifications should be called. # # When this event was fired in why_run mode we override it's status to `why-run`. # # This is also how Chef::Runner#focred_why_run is implemented so it should be reliable. # # TODO: what happens when :why_run for notification fails? # This resource was not notified by another and is a subject of normal ordered converge # process. @resource_collection_cursor is pointing to next resource according to the # expanded resource collection. # # When chef-client fails we will take remaining entries and add to the report as # 'unprocessed'. It works because resources are ordered and we can keep track where we are. # # why-run mode and notifications are not in natural order and must not move the cursor. # # Having it pointing ahead is relevant because current resource has just been converged # (maybe 'failed') and it is not 'unprocessed'. # not notified # not why-run # only converge phase
new_resource
<not_specific>