Rename post_resource_eval to post_catalog_eval?

[Jeff McCune]

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.

--

-Jeff

[Brice Figureau]

+1 for renaming, but I'd call that hook post_transaction (or
post_transaction_apply).

"Catalog evaluation" might mean a different thing based on which catalog
you are referring to (ie RAL, containment...).

--
Brice Figureau
My Blog: http://www.masterzen.fr/

[badgerious]

There was a fair amount of bumbling to get this hook named in the first the place, and clearly the name isn't satisfactory still. I think it's difficult because different names make sense depending on the perspective you look at the hook from (as Brice suggested). Maybe it would be useful to draw up a type/provider lifecycle picture that makes the terminology clear and indicates where all existing hooks are executing (the older hooks, e.g. 'flush', are even less descriptive) and drop that into the Puppet doc website somewhere? Especially as more hooks are added, I think this would be helpful.

Eric

[Trevor Vaughan]

Eric,

I attempted to do some of that for the 2.7 series https://www.onyxpoint.com/type-and-provider-execution-walkthrough/.

It might be a place/way to start.

Thanks,

Trevor

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/b1da33e5-512b-4763-b12e-3705820d8221%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[badgerious]

Trevor,

Cool! Something like an augmented version of the flowchart you've done up would be handy.

Eric

[Nan Liu]

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.

resource_type_a
resource_type_a

...

resource_type_a_post_resource_eval

resource_type_b (can I require resource type A's post resource eval?)

Thanks,

Nan

[Jeff McCune]

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 <je...@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?

 

--

-Jeff

[James Sweeny]

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

[Trevor Vaughan]

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

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAKDACKu0%2BaJnrVO-N8P4mgKvTQ08hrABdsR6wQXCyifobsnrRQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Jeff McCune]

Cool, so it sounds like we have consensus on post_resources_eval?  If so, I'll take on putting together a pull request for the rename (unless someone else would like to work on it?)

-Jeff

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.

--

-Jeff

[badgerious]

I'm bringing this thread back to life because I've found myself with some time to work on puppet things, and plan to make use of the post_resource(s)_eval hook. I notice it still has the original name as of 3.6. So I've come to ask that the name not be changed. It's pretty annoying to have API methods changing around and requires nasty version checking logic if you need compatibility with older versions (I in general do). We can still have a post_resource_eval instance method (in addition to the existing class method).

Eric