[chef] Re: Re: Re: after_created in LWRPs

[Daniel DeLeo < >]

On Monday, May 6, 2013 at 9:35 PM, Peter Donald wrote:

Hi,

On Mon, May 6, 2013 at 1:53 AM, Daniel DeLeo < "> > wrote:

I'd advise not to rely on callbacks and side-effects like this. Someone

who's not familiar with this is gonna have a bad time trying to figure out

where the data comes from.

That's not really a concern. There are plenty of things in our chef

environment that violate the naive phased model (i.e. chef_gem,

use_inline_resources in LWRPs etc). As long as there is clear

documentation I don't see it as an issue.

You can of course do whatever works for your team, but my advice is to always write code such that when it breaks the path from the symptom to the cause is as obvious and direct as possible. Documentation is great, but in practice you usually need to spend some time debugging before it's even clear what docs you need to read. And of course docs can be incomplete or out of date, and this is usually not discovered until you're debugging behavior that differs from what the docs say it should be.

 

Why not use another LWRP or resource definition that wraps both?

We need the LWRP to define the attribute so it is accessible later in

the compile phase (it is used to configure the creation of other

resources during compile). A resource definition would be nice except

that in every case we want to notify if an action is taken.

Since a resource definition is a compile time macro, you can notify the resources that the definition evaluates to. For example, the old runit_service definition created a service resource you could notify. But this is ugly because it's non-obvious and restricts your options for changing the implementation later.

Thanks!

--

Cheers,

Peter Donald

 

-- 

Daniel DeLeo