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.
Archive powered by MHonArc 2.6.16.