Deprecation: Custom Resource Cleanups (CHEF-5)
We are continuously improving and streamlining the way custom resources work in Chef, to make it easier for cookbook authors and Chef developers to build resources.
This page documents many deprecations over the course of many Chef releases.
In current versions of Chef,
nil was often used to mean that a
property had no good default, and needed to be set by the user. However,
it is often to useful to set a property to
nil, meaning that it is not
set and should be ignored. In Chef Infra Client 13, it is an error to set
default: nil on a property if that property does not allow
nil as a
If it is valid for the property to be set to nil, then update the property to include that.
property :my_nillable_property, [ String, nil ], default: nil
Otherwise, remove the
default: nil statement from the property.
Current versions of Chef emit a warning when a property’s default value is not valid. This is often because the type of the default value does not match the specification of the property. For example:
property :my_property, [ String ], default: 
sets the type of the property to be a String, but then sets the default to be an Array. In Chef Infra Client 13, this will be an error.
Ensure that the default value of a property is correct.
When writing a resource in Chef Infra Client 12, calling
behaves as a getter, returning the value of
some_property. In Chef
Client 13, this will change to set
some_property when retrieving the value of
Specifying both “default” and “name_property” on a resource
Current versions of Chef emit a warning if the property declaration has
name_property set. In Chef Infra Client 13, that will
become an error. For example:
property :my_property, [ String ], default: , name_property: true
A property can either have a default, or it can be a “name” property (meaning that it will take the value of the resource’s name if not otherwise specified), but not both.
Some providers override the
provides? method, used to check whether
they are a valid provider on the current platform. In Chef Infra Client 13,
this will cause an error if the provider does not also register
themselves with the
def provides? true end
provides :my_provider def provides? true end
do not use the updated method
updated=(true_or_false) method is deprecated and will be removed
from Chef Infra Client 13. This method never performed its intended job, as
notifications from the resource would not fire, and in general its use
has always been buggy. The Chef Infra Client notification code checks
updated_by_last_action? instead, so setting that is recommended as a
substitute. See the
documentation for more information.
updated_by_last_actionis almost always unnecessary, and correct use of
use_inline_resources(which is the default in Chef Client 13 and above) makes the
updated_by_last_actionsetting redundant. Simply deleting this code is likely to be the correct course of action in most cases.
action :foo do updated = true end
action :foo do new_resource.updated_by_last_action true end
do not use the dsl_name method
dsl_name method is deprecated and will be removed from Chef Infra Client. It has been replaced by
my_resource = MyResource.dsl_name
my_resource = MyResource.resource_name
do not use the provider_base method
Resource.provider_base allows the developer to specify an
alternative module to load providers from, rather than
It is deprecated and will be removed in Chef Infra Client 13. Instead, the
provider should call
provides to register itself, or the resource
provider to specify the provider to use.