[[chef-dev]] Re: [[chef-dev]] Lightweight Resources and Providers

[Adam Jacob < >]

On Wed, Aug 26, 2009 at 10:25 PM, Mark 
V<
 >
 wrote:
> Hi Adam,
> I'm in the middle of another task so this is a little off the cuff...
> I know I'll be using Chef later so thought to start getting my feet
> wet as the opportunities arise.
> No doubt not everything is fully developed, so I apologize if this
> misses the point :)

No need to apologize :)

> Interesting ideas.  I am not a Chef or ruby guru.  That disclaimer
> aside I have a couple of observations.
> 1) For people familiar with Ruby an attraction of Chef is they have
> fewer idiosyncrasies to wrestle against or learn - Chef requires a
> lower investment and it increases the return of their Ruby investment:
> +2 Chef.
> 2) For people unfamiliar with Ruby and who are learning Chef, Chef's
> preference for "simple, traditional ruby - no magic at all" means when
> they understand how something is done in Chef they have learned how
> something is done in Ruby - this increases the return they get for
> investing the time to learn Chef: +1 Chef.

I absolutely agree with you here.

> With that spirit/objective in mind:
> I wondered why a <particular> 'Provider' was not described as, and
> behaves as, an instance of a <particular> 'Resource' class?

Essentially a Resource is a description of something you would like to
have done - a Provider takes a Resource as its input and actually does
the work.  The important bit here is that there is a single
description for the 'kind' of thing you are dealing with (say, a
Package) but the underlying implementation may differ wildly (think
apt vs tarballs.)

So every time you do:

r = file "/tmp/foo" do
  owner "adam"
end

r is an instance of Chef::Resource::File.  If you were to then do:

r.run_action(:create)

You would look up the correct Provider for your platform (in this
case, Chef::Provider::File), create an instance of it, and pass the
resource in.  Currently there is only one provider for File resources
- but think about, say, Windows - the mechanisms required to set file
permissions are entirely different.  The results would be the creation
of a Chef::Provider::WindowsFile, etc.

> This has the advantage of eliminating 'one-more-thing-to-track' - Providers.
> I also thought 'implementation' might be a more natural term than provider?

You're always going to have to track the split of functionality
between the way you describe a thing and the actual steps required to
bring that description into reality.  Calling the thing that does the
work a 'Provider' was likely a mental-hold-over from understanding how
Puppet works internally, honestly.  I do like the word Provider better
than 'Implementation', if only because 'Implementation' is already
quite loaded.

> In the wiki example I had expected to see discussed things like:
> Class.new, Klass.inherited, Klass.included or Klass.extended
>
> For the File example:
> Perhaps with the inherited/included/extended method mixing in modules,
> found as required:
> cookbooks/opscode/resource/{include,extend}/file.rb
>
> You could still have the attribute method's shorthand, example:
>  attribute :checksum, :regex => /^[a-zA-Z0-9]{64}$/
>
> It could just be a method invoked on the resource class, example:
> Chef::Resource::File.attribute :path, :kind_of => String

That is exactly what is happening under the hood.

resource :foo { attribute :path, :kind_of => String }

Would be the equivalent of:

class Chef::Resource::File < Chef::Resource
  attribute :path, :kind_of => String
end

And you could easily write it that way instead.

> Where:
> class ::Chef::Resource::File < Chef::Resource
>  # Chef::Resource.inherited(...) now will include/extend
> cookbooks/opscode/resource/{include,extend}/file.rb, if it exists :)
> end

You'll already be doing that by default - if you wanted to re-open
Chef::Resource::File, you could just do it in the file directly - no
extra directory magic needed.

> An advantage of this is that it could allow you to have several
> instances (of one provider, using the wiki's terms) of the resource
> available at once, e.g. several MySQL servers running on different
> ports on one machine.

This is exactly what you get already with Chef - because Resources are
un-coupled from providers, you can have as many mysql servers as you
want, in as many configurations as you want. :)

Adam

-- 
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: