[chef] Re: Best practices: Search dynamically using templates in attributes

[Peter Donald < >]

Hi,

I am going to be really annoying and say "it depends". If the cookbook is only ever likely to be used by your company then make it as simple and specific as possible. If however you plan on making it usable by others, or at least other projects within your company then make it configurable ...

On Thu, Jan 31, 2013 at 8:26 PM, Maxime Brugidou < " target="_blank"> > wrote:

The current state of things in the cookbooks we encountered (from Opscode and others, like OpenStack), is:

1. Specify a role name to search on and optionally set an attribute to search within an environment.

I dislike this. It rarely works for our infrastructure as we tend to use the "role cookbook" [1] approach and thus rarely have the same types of roles as the original implementers intended.

 

2. Sometimes (for example rsyslog) you can directly specify a search query in the node attributes. This is slightly more flexible but the search is still defined by a static attribute. 

I think that defining a search query as an attribute is the right approach. Many people want to limit the search to nodes in a particular environment, in a particular state, or in a particular data center etc.

 

All this works fine but sometimes you want to dynamically allocate clusters using various logic (from ohai data like datacenter, or by environment or a combination of attributes). The classic example is if you have N datacenters and don't want to create a role for each datacenter.

One solution would be to create a "site-specific" (or "glue") cookbook that will define dynamically the search string at compile time. This is perfectly OK but adds cookbooks.

This is exactly what we do. A so called "wrapper" cookbook [1]. However our wrapper cookbook tends to define the search string and then set the node attribute before calling the main cookbook that uses search string.

nodes = search(:node, eval("\"#{node[:my_app][:nodes_search]}\"")) 

Is this pattern reasonable? Or should we stick to the "glue" cookbook way? Or is there anything else we can use?

I think that using eval may lead to some issues and a little more complexity. I would tend to go with the "wrapper" (a.k.a. "glue" or sometimes "application" cookbook).

[1] http://realityforge.org/code/2012/11/19/role-cookbooks-and-wrapper-cookbooks.html

-- 
Cheers,

Peter Donald