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 <[email protected]>wrote: > > > > On Fri, Mar 7, 2014 at 1:16 PM, Jeff McCune <[email protected]> wrote: > >> On Fri, Mar 7, 2014 at 7:45 AM, Nan Liu <[email protected]> wrote: >> >>> On Thu, Mar 6, 2014 at 10:16 PM, Jeff McCune <[email protected]>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 [email protected]. > 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 [email protected] -- 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 [email protected]. 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.
