Deprecation: resource_name declaration without provides (CHEF-31)
In Chef Infra Client 12.5.1 through 15, resources could be addressed from
recipe code using only the name of the resource, provided that no other
provides declaration was used in the same file.
The intent was to fulfill the demands that “users should just be
able to name a resource and it should work” with the demands that, for
more complicated use cases, users should be able to use
lines to arbitrarily wire up resources to the Chef recipe language.
This failed because it attempted to overly simplify user intent while
generating two separate constructs with confusing interactions. Most
users were entirely unaware that the
resource_name statement implicitly
provides statement which wired up a specially designated
canonical DSL entry, which was then removed behind the scenes if any
provides declaration followed. When this worked it was
easy to use, but when it failed the edge conditions were confusing and
required too much background knowledge to debug.
An attempt was made to preserve more complete backwards compatibility between
Chef Infra Client 16.0 and earlier versions by retaining some automatic
wiring of the
provides statement with the
resource_name. This failed
due to complicated interactions between cookbooks that used multiple
resources with the same name wired up using
provides lines to different
resource implementations on different operating systems. This was a silent
error and dependent upon the parse order of the resources in the cookbook
for it to become apparent, and hindered detection and remediation.
The solution eventually adopted in Chef Infra Client 16.2 was to require
all resources to declare a
provides lines, and to make the
setting only affect the display output. As a result, any cookbook which
declares a resource with only a
resource_name needs to add a
line for Chef Infra Client 16. While this is more disruptive to users it
is simple, it can be autocorrected using static analysis, and it results in
a much simpler end state where the
resource_name is just a display name
provides statement is solely responsible for how the resource
is addressed in recipe mode.
There is also the old standard that existed before resources could
declare what they provided. In that standard, the resource was addressed
by prepending the
cookbook_name to the filename that the resource was declared in.
That has remained unchanged and is not affected by this change.
A resource with only a
resource_name :my_custom_resource property :my_property, String action :run do [ ...implementation of the action... ] end
Should have a
provides statement added:
resource_name :my_custom_resource provides :my_custom_resource property :my_property, String action :run do [ ...implementation of the action... ] end
It also works to have the
provides line come before the
the order does not matter.
For cookbooks which do not have to support Chef Infra Client 15 or before, the
resource_name can also be entirely omitted:
provides :my_custom_resource property :my_property, String action :run do [ ...implementation of the action... ] end