[chef] Re: Re: RE: Re: Re: Conditional execution for custom resources


Chronological Thread 
  • From: Peter Donald < >
  • To:
  • Subject: [chef] Re: Re: RE: Re: Re: Conditional execution for custom resources
  • Date: Wed, 20 Mar 2013 11:10:11 +1100

Hi,

On Wed, Mar 20, 2013 at 5:20 AM, Jay Feldblum 
< >
 wrote:
> Using custom providers like glorified definitions is poor form. If you have
> a provider which simply declares some sub-resources, why is that a provider?

If it is in a reusable cookbook then;
* you want to be able to add notifications/subscriptions to it.
* I find the ease of validating configuration passed into a LWRP much
easier than definitions.
* We started down the path of generating user documentation based on
annotations in the resource aspect of the LWRP.

If it is not a reusable cookbook then definitions are fine but I often
find a raw ruby method easier to digest.

On Wed, Mar 20, 2013 at 8:11 AM, Daniel DeLeo 
< >
 wrote:
> As for notifying resources that are defined by a macro, that feels a bit
> ugly because you're crossing the abstraction layers. Can you explain a bit
> more about how you're using this profitably?

Here's how we use this. I am not sure if it is "good practice" but we
have yet to find a better mechanism.

Almost all of our cookbooks with LWRP use the inline-resources
strategy. Some of our LWRPs define resources that they want external
elements to be able to subscribe to or notify on. Typically this is
something like a LWRP that defines a service and we want to be able to
restart service when configuration managed by other components gets
changed. i.e. We have to restart an application server when a hosted
application changes certain configuration elements.

We have solved this in a number of different ways. Typically we just
redefine the resource that we need to notify on with a :nothing action
and notify as appropriate. Mostly this works. Some of our cookbooks
redefine the same resource 10+ times in different LWRPs which is
annoying. In the case of services this is even more annoying because
we want to make the particular service provider configurable at
runtime (i.e. runit/upstart/....) which would mean some painful
configuration across LWRPs.

We have toyed with the idea of having a mechanism for allowing a LWRP
to "publish" some resources into a higher context and keep some inline
but it seemed complex to implement so we avoided it.

-- 
Cheers,

Peter Donald



Archive powered by MHonArc 2.6.16.

§