General discussion about Chef

[chef] Re: Re: Re: RE: Re: Re: Re: RE: Augeas support


Chronological Thread 
  • From: Andrea Campi < >
  • To: " " < >
  • Subject: [chef] Re: Re: Re: RE: Re: Re: Re: RE: Augeas support
  • Date: Tue, 19 Feb 2013 14:53:41 +0100
Thom,

I don't think you're overthinking it…

If we go down this path, apache2 should probably be a "pure virtual" cookbook; you would then have apache2_debian or apache2_redhat. Obviously apache2 would not depend on either, so it's your responsibility to put the correct one on the run list.

Each "concrete" cookbook would set an attribute to advertise itself to the apache2 cookbook.

LWRPs like apache2_module would only be facades that would delegate to apache2_debian_module as appropriate (depending on that cookbook).

This would be mildly boring but easy work. What would be harder is implementing apache2_redhat in a meaningful way that is also backward compatible with existing cookbooks.

A 



On Tue, Feb 19, 2013 at 2:44 PM, Thom May < " target="_blank"> > wrote:
On Tue, Feb 19, 2013 at 1:26 PM, Cassiano Leal < " target="_blank"> > wrote:

-----Original message-----
> From:Joshua Timberman <
 
 " target="_blank">
 >
> 
> By all means, don't use the community cookbook if it doesn't fit your preference, use case, supported platforms or standards.




Totally understood. Unfortunately, when it comes to such a basic cookbook as Apache, that means foregoing a very large share of the benefit of Chef - too many community cookbooks depend on it.
I have been thinking about this problem for a while now. I believe that what Chef needs here is something similar to Virtual Packages on the Debian packaging system.

Basically, abstract notions of a functionality, whose actual implementation is delegated to one or more packages (or in Chef's case, cookbooks).

I really like the idea of "virtual" cookbooks. But...

The real problem here is that you then get into the API of the cookbook - if I say I "depends apache2" then what i really mean is that i expect to be able to call the apache2_module LWRP and have it do the right thing. 

But what happens when the opscode cookbook changes the semantics of the LWRP (and does it right, bumps the major version etc). How do you express the version number of the LWRP? Do all apache2 cookbooks have to have the same version number?

Or are we actually talking about a "SONAME" of a cookbook, which becomes a collection of "symbols" (LWRPs in this case) with specific versions. Then I can say I actually want apache2_module ~> 2.0 and don't care about anything else in the cookbook. 

Or is this overthinking the problem?


Archive powered by MHonArc 2.6.16.

§