I think this hits the nail on the head. post_resources_eval ==> after all the resources of this type post_resource_eval ==> after this resource
And, yes, we need both as well as post_catalog_eval! I'd personnal prefer that there is not an explicit failure state between these but, instead, state data that is passed between them. post_resource_eval -> Hash(success_status) -> post_resources_eval -> Hash(success_status) -> post_catalog_eval. This way you can do different things based on what happens as a controlled cascading failure without digging through the entire catalog. Also, it would be nice for the failure state to be part of each run (and reset) in such a way that dependent resources (autorequires, etc...) can make a decision based on the state of what it's depending on. Trevor On Fri, Mar 7, 2014 at 3:09 PM, James Sweeny <james.swe...@puppetlabs.com>wrote: > > > > On Fri, Mar 7, 2014 at 1:16 PM, Jeff McCune <j...@puppetlabs.com> wrote: > >> On Fri, Mar 7, 2014 at 7:45 AM, Nan Liu <nan....@gmail.com> wrote: >> >>> On Thu, Mar 6, 2014 at 10:16 PM, Jeff McCune <j...@puppetlabs.com>wrote: >>> >>>> This is just a continuation of a previous thread as to not hijack the >>>> original discussion. >>>> >>>> The question that needs a decision is, should post_resource_eval be >>>> renamed given the context that it's currently implemented as a hook into >>>> the point after all resources for a provider are evaluated and we might >>>> want a hook into the point after each discrete resource is evaluated? >>>> >>>> Nan agrees it should be renamed hence the need for a decision. >>>> >>> >>> I'm not sure where this should be documented (is there a ticket?). There >>> is one more challenge for post_resource_eval v.s. post_catalog_eval. I >>> believe there is a need to be able to establish a dependency to >>> post_resource_eval. >>> >> >> >> Yeah, I'm thinking the idea of "post catalog eval" is flawed because it's >> really not after the _catalog_ but rather all provider instances for a >> given resource type. There may still be quite a bit of the catalog left to >> evaluate when the hook fires. >> >> post_type_providers_eval maybe? >> >> >> > post_resources_eval as opposed to post_resource_eval? Is that too small a > syntactic distinction? > -- > > James Sweeny > Professional Services > http://puppetlabs.com/ > > *Join us at PuppetConf 2014, September 23-24 in San Francisco - * > http://bit.ly/pupconf14 > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CAKDACKu0%2BaJnrVO-N8P4mgKvTQ08hrABdsR6wQXCyifobsnrRQ%40mail.gmail.com<https://groups.google.com/d/msgid/puppet-dev/CAKDACKu0%2BaJnrVO-N8P4mgKvTQ08hrABdsR6wQXCyifobsnrRQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVS037yAOj5FNNVybxhQQ7p_WnAmj5Rs3dDVr8fKS5pBA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
