Writing a provider

Hi all,

I’ve read several time the doc an LWRP, but I’m still a bit lost on how to
do it. If someone is kind enough to answer a few questions:

  • are an instance of a provider created for each resource it processes ?
  • http://docs.opscode.com/lwrp_custom_provider.html :
    • “The load_current_resource method is used to find a resource” => does
      this mean I have to write this method ? is it called by chef ?
  • "The current_resource method is used to represent a resource " => might
    be nice to see it in the code snippet, is it the same as @current_resource ?
  • where is the normal place to persist downloaded file ?
  • is there a way to share state between all resource processing during a
    chef run:
    foobar "a"
    foobar "b"
    if foobar is supposed doing a long computation can he save it somewhere the
    first time foobar “a” is processed to be able to reuse it when foobar "b"
    is processed ?

thanks for your time,
Alex

On Friday, October 25, 2013 at 1:39 AM, Alexandre Russel wrote:

Hi all,

I've read several time the doc an LWRP, but I'm still a bit lost on how to do it. If someone is kind enough to answer a few questions:

  • are an instance of a provider created for each resource it processes ?

A provider is created for each action on each resource. Most of the time a resource only has one action, but it can have more, for example action :enable, :start on a service is common.

That depends on what you’re doing. If your LWRP just runs some other chef resources, you don’t need to bother with this at all. If your LWRP is using custom ruby code to modify the system, then you might want to write this. Its purpose is to examine the existing state of the system and populate a resource object with data describing that state.

  • "The current_resource method is used to represent a resource " => might be nice to see it in the code snippet, is it the same as @current_resource ?
    Yep, this is just an attr_accessor.
  • where is the normal place to persist downloaded file ?

Chef::Config[:file_cache_path]

  • is there a way to share state between all resource processing during a chef run:
    foobar "a"
    foobar "b"
    if foobar is supposed doing a long computation can he save it somewhere the first time foobar "a" is processed to be able to reuse it when foobar "b" is processed ?

Depends on what exactly you’re doing. One option is node[:run_state] which is a regular ruby Hash object which is tied to the lifecycle of the chef run.

thanks for your time,
Alex

--
Daniel DeLeo

very helpful, thanks for your help

On Fri, Oct 25, 2013 at 5:59 PM, Daniel DeLeo dan@kallistec.com wrote:

On Friday, October 25, 2013 at 1:39 AM, Alexandre Russel wrote:

Hi all,

I've read several time the doc an LWRP, but I'm still a bit lost on how
to do it. If someone is kind enough to answer a few questions:

  • are an instance of a provider created for each resource it processes ?

A provider is created for each action on each resource. Most of the time a
resource only has one action, but it can have more, for example action :enable, :start on a service is common.

That depends on what you’re doing. If your LWRP just runs some other chef
resources, you don’t need to bother with this at all. If your LWRP is using
custom ruby code to modify the system, then you might want to write this.
Its purpose is to examine the existing state of the system and populate a
resource object with data describing that state.

  • "The current_resource method is used to represent a resource " =>
    might be nice to see it in the code snippet, is it the same as
    @current_resource ?

Yep, this is just an attr_accessor.

  • where is the normal place to persist downloaded file ?

Chef::Config[:file_cache_path]

  • is there a way to share state between all resource processing during a
    chef run:
    foobar "a"
    foobar "b"
    if foobar is supposed doing a long computation can he save it somewhere
    the first time foobar "a" is processed to be able to reuse it when foobar
    "b" is processed ?

Depends on what exactly you’re doing. One option is node[:run_state] which
is a regular ruby Hash object which is tied to the lifecycle of the chef
run.

thanks for your time,
Alex

--
Daniel DeLeo