Understanding lwrp development

Copyright © 2010 Opscode, Inc - All Rights Reserved
Speaker:
‣ joshua@opscode.com
‣ @jtimberman
‣ www.opscode.com
Joshua Timberman Technical Evangelist
1
Understanding LWRP
Tuesday, November 2, 2010

Chef manages
Resources on Nodes
2
cookbook_file
template
service
package
deploy
git
http_request
link
ruby_block
log
bash
execute
remote_file
user
Resources are an abstraction we feed data into. When you write recipes in Chef, you create
resources of things you want to conﬁgure. You describe the state of some part of the system.
We’re going to talk about how this works in depth.

Copyright © 2010 Opscode, Inc - All Rights Reserved 3
gem_package "bluepill"
A very simple resource, simply tells Chef to install the bluepill package as a RubyGem.

package "bluepill" do
provider Chef::Provider::Package::Rubygems
end
package "bluepill" do
provider gem_package
end
Likewise, these are both the equivalent of the previous gem_package, we’re just speciﬁcally
telling the package resource to use a particular provider. We’ll see why this matters later.

template "/etc/bluepill/dnscache.pill" do
source "dnscache.pill.erb"
mode 0644
end
Another somewhat simple resource, specify a ﬁle to be written somewhere as a template.

bluepill_service "dnscache" do
action [:enable,:load,:start]
end
Here’s a custom resource that speciﬁes actions to run. We’ll talk in a bit how this works.

Resources take action
through Providers
7
The abstraction over the commands or API calls that will conﬁgure the resource to be in the
state you have deﬁned.

service "dnscache" do
provider bluepill_service
action [:enable, :load, :start]
end

Chef’s Recipe DSL
creates resources

Recipes evaluated in two phases
10
Compile Phase
Execution Phase
Going to leave out some of the details. The rest is in the code. :)

Compile Phase
11

Resources added to
ResourceCollection
12
When recipes are processed for Resources during the compile phase, they are added to the
resource collection. These can include..

Chef::ResourceCollection
13
Resources and definitions
Hash of indexed resources
Definitions are replaced
Chef “recognizes” resources and definitions through method_missing. These are created as a
hash of numerically indexed resources. Definitions are replaced entirely by the resources they
contain.

@resources_by_name={"file[/tmp/something]"=>0}
essential what the Resource Collection looks like.

Chef::RunContext
Loads cookbook components
‣ Libraries
‣ Providers
‣ Resources
‣ Attributes
‣ Deﬁnitions
‣ Recipes
The order is important because of where you can put things, and when things are available.

Execution Phase
16
Once everything is loaded up and the recipes have been parsed for the resources they
contain, the runner starts the execution phase.

Chef::Runner converges
the node
runs the provider actions speciﬁed by the resource

Chef::Resource calls
run_action
18
run_action calls the method for that particular action in the provider

Provider is chosen by
Chef::Platform
19
This is how platform speciﬁc providers are chosen like apt/yum, useradd, etc. It also contains
logic to get the provider for the resource..

Chef::Platform finds the provider
20
Specifically named parameter
Platform assigned providers
Matching the resource name
Specifically named providers are like we saw earlier where the resource itself had the provider
parameter.
Platform assigned are the ones like apt/yum for packages.
Matching the resource name is how LWRPs get chosen.

Cookbook LWRP
21
LWRPs, or resources and providers written in this special DSL, reside in cookbooks.

Ruby DSL for writing
Resources & Providers
22
All LWRPs are, a Ruby DSL for writing resources and providers. This DSL is designed to be
easier to write and understand than the fully resource/provider code in the code included by
the Chef libraries.

Resources have states
23

Resources have states
24
Resource DSL describe states
Two possible states
‣ Current (@current_resource)
‣ Desired (@new_resource)
Providers load_current_resource
The resource describes the state that some aspect of the system should be in by passing
parameters that conﬁgure it for that state.
Current and desired are the two states that a resource can be in.
Providers load_current_resource determines what state the resource is in.

def load_current_resource
@bp = Chef::Resource::BluepillService.new(new_resource.name)
@bp.service_name(new_resource.service_name)
Chef::Log.debug("Checking status of service #{new_resource.service_name}")
begin
if run_command_with_systems_locale(:command => "#{node['bluepill']['bin']} status #
{new_resource.service_name}") == 0
@bp.running(true)
end
rescue Chef::Exceptions::Exec
@bp.running(false)
nil
end
if ::File.exists?("#{node['bluepill']['conf_dir']}/#{new_resource.service_name}.pill")
&& ::File.symlink?("#{node['bluepill']['init_dir']}/#{new_resource.service_name}")
@bp.enabled(true)
else
@bp.enabled(false)
end
end
The code is not important. What is important that we’re checking for some various states on
the system by running commands or code and setting “state” parameters.

actions :start, :stop, :enable, :disable, :load, :restart
attribute :service_name, :name_attribute => true
attribute :enabled, :default => false
attribute :running, :default => false
attribute :variables, :kind_of => Hash
attribute :supports, :default => { :restart => true, :status => true }
Resource DSL
Actions correspond to ‘action’ methods in the provider.
Attributes correspond to methods for the resource. These are also called parameters and are
not node attributes.

Provider DSL
27
action :start do
unless @bp.running
execute "/usr/bin/bluepill start #{new_resource.service_name}"
end
end
The provider DSL at a minimum has action methods. The action methods handle doing
whatever is needed to conﬁgure the resource to be in the declared state.
Earlier we set @bp_running to true or false depending on the current state, here we check.

action :start do
unless @bp.running
end
end
Lets break down the provider’s methods

def load_current_resource
@bp = Chef::Resource::BluepillService.new(new_resource.name)
@bp.service_name(new_resource.service_name)
Chef::Log.debug("Checking status of service #{new_resource.service_name}")
begin
if run_command_with_systems_locale(:command => "#{node['bluepill']['bin']} status #
{new_resource.service_name}") == 0
@bp.running(true)
end
rescue Chef::Exceptions::Exec
@bp.running(false)
nil
end
if ::File.exists?("#{node['bluepill']['conf_dir']}/#{new_resource.service_name}.pill")
&& ::File.symlink?("#{node['bluepill']['init_dir']}/#{new_resource.service_name}")
@bp.enabled(true)
else
@bp.enabled(false)
end
end

action :start do
unless @bp.running
end
end

action :start do
unless @bp.running
end
end
Chef Resources! New resource parameters
You can use chef resources inside LWRPs, too.
The goal: Replace deﬁnitions with LWRPs

LWRPs in Opscode Cookbooks
32
aws_ebs_volume
aws_elastic_ip
bluepill_service
daemontools_service
dynect_rr
mysql_database
pacman_aur
pacman_group
samba_user
built from the name of the cookbook and the ruby ﬁle in the resources/providers directory.
these are the aws, bluepill, daemontools, dynect, mysql, pacman and samba cookbooks
respectively.

Understanding lwrp development

More Related Content

What's hot (19)

Similar to Understanding lwrp development (20)

More from jtimberman (10)

Understanding lwrp development