[chef] Re: Re: Re: Good example of a lwrp

Chronological Thread 
  • From: Jay Feldblum < >
  • To:
  • Subject: [chef] Re: Re: Re: Good example of a lwrp
  • Date: Sat, 1 Dec 2012 10:26:22 -0500


Providers typically detect the current state of the system (the "current resource"), compare that state to the state declared in the recipe (the "new resource"), and figure out what actions it needs to take to modify the system to bring it into compliance with the new resource.


On Sat, Dec 1, 2012 at 9:00 AM, Kevin Christen < " target="_blank"> > wrote:

Thanks for providing these examples; I learned a few things from them. One question for you or anyone else on the list though. This line from the samba provider's load_current_resource method confuses me:

 @smbuser = Chef::Resource::SambaUser.new(new_resource.name)

I assume that Chef::Resource::SambaUser is the class generated from the LWRP resource. So isn't new_resource already an instance of that class?

Kevin Christen

On Fri, Nov 30, 2012 at 11:32 AM, Joshua Timberman < " target="_blank"> > wrote:

On 11/30/12 9:31 AM, "Maven User" < " target="_blank"> > wrote:

>I'm still on my quest to simplify our deployments and was wondering if
>there is a good demo/example/sample I can look at to create my own LWRP?
>I can see how to create the resource, but the provider bit is kinda

First, LWRPs are specifically the lightweight DSL that doesn't require the
ruby class structure. "Heavyweight" resources/providers are like the ones
that come with Chef itself. The "database" cookbook implements its
resources/providers as heavyweight due the way that the LWRPs are
automatically named by the cookbook and the filenames, and we wanted to

Second, the key is to make your resources idempotent. This is easy if
you're using resources inside the action blocks in the provider, and the
examples (below) have some of that. In some cases, like when you're
chaining together a bunch of command execution, you'll want to use
"load_current_resource" to check the current state of the system.

There are more advanced considerations, such as why-run support, and
handling updated resources, but for now stick to a simple use case.

These LWRPs from Opscode's cookbooks are relatively simple examples:




As an exercise, I'd probably start by doing an LWRP that simply handles
dropping off a "conf.d" style of configuration file.

Hope this helps!

Opscode, Inc
Joshua Timberman, Technical Community Manager
IRC, Skype, Twitter, Github: jtimberman

Archive powered by MHonArc 2.6.16.