[chef] Re: Re: Re: Re: Re: More on Cookbook Design Patterns

[Jay Perry < >]

Thanks Lamont, this discussion has been enlightening to me.  I appreciate 
what you and Tom have provided for information, it has been very helpful.  I 
hope at a later time I can write something up about our experience 
transitioning from what we have to a more modular design capturing the 
challenges and decisions we made along the way.  Again thanks for the help.  
Hopefully we can have more discussions in the future.

-- Jay

> On Apr 3, 2014, at 5:38 PM, Lamont Granquist 
> <
 >
>  wrote:
> 
>> On Thu Apr  3 14:17:56 2014, Jay Perry wrote:
>> Okay, so is the acme_tomcat_server cookbook app specific or a platform 
>> cookbook that can be shared?  If myapp need special configuration or extra 
>> setup very specific to myapp can that go in myapp::default?  I guess in 
>> your example is the myapp cookbook serving a dual role.  It manages what 
>> the role would have done and it handles app specific settings and any 
>> specialized setup?  For example say "myapp" required a special mongo setup.
>> 
>> -- Jay
>> 
>>>> On Apr 3, 2014, at 5:03 PM, Lamont Granquist 
>>>> <
 >
>>>>  wrote:
>>>> 
>>>> On Thu Apr  3 13:38:12 2014, Jason Perry wrote:
>>>> What I'm also following is that it's probably not a good idea to combine 
>>>> the application cookbook with a role cookbook.  Currently our 
>>>> application cookbooks have replaced the roles runlist setting where 
>>>> previously the role would have a run list that was something like 
>>>> "recipe[acme_java],recipe[tomcat],recipe[groovy],recipe[myapp]" with the 
>>>> role being called "myapp".  Now the myapp default recipe has a bunch of 
>>>> include_recipe calls and the role now just has "recipe[myapp]".  When 
>>>> the node is bootstrapped the run list ends up looking like so 
>>>> "role[datacenterA],role[base],role[myapp]".  In this model I would have 
>>>> to move whatever the base role is doing down to the myapp::default 
>>>> recipe level or parts of it for testing.  I think this is probably the 
>>>> most tricky part of  it all and how to avoid too many dependencies with 
>>>> still being able to test the cookbooks purpose.
>>>> 
>>>>   -- Jay
>>> 
>>> i'd suggest that all roles do is map 1-1 with role cookbooks.  then i'd 
>>> suggest that recipe[myapp] be pretty thin and it would just setup some 
>>> attributes to point at the instance of the software to deploy and then 
>>> include_recipe something like "acme_tomcat_server".  the 
>>> acme_tomcat_server recipe would be more complicated and would express all 
>>> the dependencies including pulling in the your java cookbook, and the 
>>> actual tomcat cookbook along with monitoring and whatnot.  you might want 
>>> to have this export an LWRP that your myapp cookbook could use rather 
>>> than have it be attribute-driven.
>>> 
>>> then if installing java requires setting up an internal corporate yum 
>>> repo mirror then you would want to break that out into its own recipe and 
>>> include_recipe it there in the java cookbook.  you might also 
>>> include_recipe this from the base role cookbook as well, but that's fine. 
>>>  chef will figure that out and the yum repo will get setup before 
>>> anything that depends on it.   if you're doing your testing correctly and 
>>> expressing your dependencies correctly then you shouldn't have any issues 
>>> with this.  myapp will pick up the tomcat_server cookbook which will 
>>> pickup the java cookbook which will pickup your yum repo cookbook (even 
>>> if your base role comes after your role cookbook it should still work out 
>>> fine so long as you've tested your myapp cookbook in isolation and it has 
>>> passed -- although generally i'd suggest that base comes first so that 
>>> your user accounts get setup early so you can login to servers and 
>>> troubleshoot -- but the further down the test-driven-infrastructure road 
>>> yo
> u get, hopefully the less likely this is a real concern).
> 
> as long as the special configuration is really special to myapp then i'd 
> put it directly in myapp::default.  once you repeat yourself then you 
> should probably push that into your acme_tomcat_server cookbook.  ideally 
> all your tomcat servers use acme_tomcat_server::default.  as you create 
> slightly different common sub-flavors of tomcat servers you'll create 
> additional complexity in that cookbook.  you might switch behavior based on 
> node attributes, based on LWRP attributes, you might have different 
> versioned 'branches' (1.x vs 2.x) of the cookbook, you might have different 
> flavors of recipes, and you might even bust out two acme_tomcat_server_v1 
> and acme_tomcat_server_v2 cookbooks.  all of those different approaches to 
> handling conditional logic have their strengths and weaknesses but you 
> probably want to prefer solutions closer to the beginning of that list than 
> the end.
> 
> i would say that the myapp cookbook is a role cookbook, but i don't really 
> care about the name you give the thing.  it is a cookbook that expresses 
> what is different about myapp from your other apps (database credentials, 
> github repo, artifacts to install, special magic sauce that only gets 
> applied to myapp).  then you want another cookbook that expresses what is 
> the same between all your different tomcat apps (which probably exports 
> some LWRPs and may have a default recipe for common setup).  you write the 
> latter to look more like a library cookbook pattern where its intended to 
> be reused.  the myapp cookbook isn't intended to be reused at all.
>