[chef] Re: New Custom Resources

Chronological Thread 
  • From: Lamont Granquist < >
  • To:
  • Cc: Cassiano Leal < >
  • Subject: [chef] Re: New Custom Resources
  • Date: Fri, 09 Oct 2015 09:51:22 -0700

also you should stop using the `provider` property on resources as well.

instead of:

package "whatever" do
provider local_install? ? Chef::Provider::Package::Dpkg : Chef::Provider::Package::Apt

on Chef-12 that will wind up with package selecting an Chef::Resource::Apt resource and wrapping that around a Dpkg provider when local_install? is set and then chef will output in the run "apt_package[whatever] <log stuff>" even though its running dpkg. that is fairly 'broken' but it was always broken since in Chef-11 you were getting a vanilla Chef::Resource::Package with no support for any specific Dpkg or Apt options. that provider option was also always tight coupling to an internal chef class and was always bad as well (now we can never ever change the names of those classes or we'll break the world).

instead you should act more like:

if local_install?
  dpkg_package "whatever" do
  apt_package "whatever" do

you should have always been doing that in Chef-11 in order to reduce the tight coupling and to construct the correct resource and do the correct validation for the provider that you were using. the only problem with this is that the block is replicated and generally has copypasta code that we'd like to dry. the declare_resource API can fix that:

package_resource = local_install?  ? :dpkg_package : :apt_package
declare_resource package_resource, "whatever" do


TL;DR: write 1:1 resources with the new resources stuff and use declare_resource to switch them dynamically.

On 10/09/2015 09:24 AM, Lamont Granquist wrote:

yeah, you want 1:1 mapping of resources and providers, and then wire
them up with provides.  look at how the package resources use
yum_package resource+provider, apt_package resource+provider and then
wire themselves up to package on the DSL.  the Chef::Resource::Package
resource is now an abstract base class that isn't wired up to 'package'
any more (its just used for code sharing).  the objects that you can
really make are Chef::Resource::YumPackage and
Chef::Resource::AptPackage, and those always wrap
Chef::Provider::Package::Yum and Chef::Provider::Package::Apt.

the multiple-provider abstraction is really kind of deprecated (but not
really) because its a leaky abstraction.  once you wind up sprouting
different validations that you want to do on the two different
providers, then you want to wrap them with 1:1 specific resources that
do the validation for the specific provider.  the way that Chef 11
worked where you could get a vanilla Chef::Resource::Package that wraps
a Chef::Provider::Package::Yum but you couldn't pass any of the
yum-specific options through that was mostly confusing -- there's
possibly a bit of utility there in being able to validate that the
package options you were using were valid across all platforms, but i
don't think anyone used it that way, and only the people who really
deeply thought about the classes you were instantiating.

and if you look at the service resources with the multiple providers
behind it, it is just a disaster.  don't ever go down the road of
replicating those patterns.  that source code should come with a big
warning that its an example of a chef antipattern.

On 10/09/2015 07:42 AM, Cassiano Leal wrote:

Hi list,

I’m having a look into the newly released Chef Client 12.5 and I really like the new streamlined custom resources.

I couldn’t find information on how to deal with multiple providers in this new model though. What’s the thought around that? Create different custom resources for what used to be different providers?


Cassiano Leal

Archive powered by MHonArc 2.6.16.