[chef] Re: Wrapper cookbooks

[Gregory Patmore < >]

a side note, maybe you know this already, but include_recipe runs a recipe 
and it should not be confused with dependencies. they are related, but quite 
different in behavior. 

regarding the original question, I guess I'm not clear on what you mean by 
'wrapping' a cookbook. I am assuming you mean 'resource' when you say 
'cookbook' as I can't think of a reason to adjust everything within a 
cookbook. I apologize if this is erroneous.  

Our squad implements layers of abstraction all the time on top of 3rd party 
cookbook resources as well as core chef resources. It allows us to adjust the 
behavior of the resources for specific, custom requirements without having to 
change the base resource that is likely acceptable 99% of the time. 

However, what we do would be more accurately described as a proxy or 
composition pattern vs inheritance as the term 'wrapping' could suggest. 
Assuming adherence to standard OOP best practices, extending objects within 
chef land usually seems to lead to increased maintenance overhead and less 
flexibility over the long term, whereas defining accessor type resources that 
use the 'wrapped' resources and introduce controlled changes to behavior or 
more commonly, to abstract additional conventions established by your project 
and outside the scope of the original objects consideration, leads to higher 
agility and flexibility when those conventions change and/or a new underlying 
resource becomes desirable. 

We strictly avoid the use of include_recipe unless exhaustively justified.  
Cookbook dependencies are necessary, but should only be established via a 
cookbook's metadata file. If we proxy (wrap) a resource we try to wrap the 
entirety of the resource's interface, even if it just passes along the call 
to the proxied resource. this alleviates any need to use both, and allows us 
to implement additional log feedback and/or adjusted behavior. 

The application cookbook is likely the hardest one to deal with as it was 
intended as what one might know as an 'abstract' class/object/resource; 
intended to require extending to be of any actual use. Normally one doesn't 
see this resource being used directly but rather used via a more specific 
application derivative such as application_python or application_java. So 
some quick research on how these objects are written would likely be the best 
source for how to write a new wrapper for the application, assuming you can't 
find an extension that more closely suits your requirements. 

I hope this helps you sort it out some 
Greg



> On Mar 26, 2014, at 6:10 PM, Douglas Garstang 
> <
 >
>  wrote:
> 
> I'm having issues with wrapper cookbooks. The setup is pretty complex, so 
> I'm not even quite sure how to describe it here in a way that makes sense.
> 
> Generally speaking though, I have a wrapper cookbook that wraps an 
> application cookbook. That application cookbook includes other cookbooks. 
> Something along the way, a location cookbook is included that calculates 
> and sets some attributes.
> 
> Everything up to and including the application cookbook tests fine with 
> vagrant. However, when I try and wrap that, it fails to find attributes 
> previously set in the location cookbook. All I should need in the 
> application wrapper is a single line for the application cookbook in the 
> metadata, the Berksfile and and include_recipe, right?
> 
> The application wrapper cookbook should not need to reference anything 
> except the cookbook it is wrapping. If I put an include_recipe "location" 
> in there, it works. I don't understand this. I'm also very confused about 
> the fact that if I don't mention the location cookbook in the metadata or 
> the Berksfile, a vagrant up still shows it as grabbing it from git. Not 
> sure if that's from a dependancy, or directly.
> 
> Help appreciated.
> 
> Doug.