[chef] RE: Re: Re: application cookbook "annoyances"


Chronological Thread 
  • From: Kevin Keane Subscription < >
  • To: < >
  • Subject: [chef] RE: Re: Re: application cookbook "annoyances"
  • Date: Tue, 12 Feb 2013 11:16:37 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=sendgrid.info; h=subject :from:to:mime-version:content-type:in-reply-to:references :sender; q=dns; s=smtpapi; b=auLwxa6ZY4WeCXCaV6NCi3H6wK52oUhBz/E UUJ0wAMHCgui6YceW5dSQb+ySkbyLbgJtOSQai54w0rrtp/o+FLkBy0RdQXa0ccX KAHD/Y9g+bS2Ukbc97LuChAqwfYzyMoT5/RL2t7eJ/dk0avfCBA9F6R0oCqnCGB3 Dp8IPtfc=

Title: RE: [chef] Re: Re: application cookbook "annoyances"

It seems to me that both patterns have their place. Roughly speaking, a dedicated attribute seems the best pattern to find a server, and a search is best when you are looking for clients.

 

Searching for a particular role or recipe breaks when you set up several of the same kind of server, but want a particular client to connect to a specific one. Examples are that you might have several database servers, several backup servers, or several rsyslog servers. In fact, there were one or two community recipes I couldn't use for this reason (can't remember which ones off the top of my head).

 

On the other hand, when the server needs a list of clients, you can often best use a search to find all of them automatically.

 

I sometimes go a step further, and when I create a recipe, I have a *single* recipe for both client and server, and an attribute that holds the fqdn of the server. The recipe uses it to identify whether it should act as client or as a server, and then if it's a client, it uses the same attribute to find the correct server among multiple ones.

 

-----Original message-----

From: Torben Knerr < >
Sent: Tue 02-12-2013 03:36 am
Subject: [chef] Re: Re: application cookbook "annoyances"
To: ;
Thanks Joshua,
 
I like the approach of the rsyslog cookbook more as it does not rely on roles but rather uses a dedicated attribute to distinguish client & server. 
 
For the other cookbooks doing "recipe:" or "role:" searches, doing an alternative search and re-opening template in the application cookbook would be a workaround. Still, it's a workaround and relies on the implementation details of the worked-around cookbooks. 
 
Someone mentioned that with Chef 11 the `include_recipe`d recipes would be visible in the run_list (or some expanded form of it). Is that true? I can hardly imagine this as the `include_recipe`s are dynamic and thus can only be determined after the recipes have been evaluated but not in advance, isn't it?
 
At least I have some ideas now how to go further...
 
Cheers,
Torben
 
 


On Sun, Feb 10, 2013 at 12:30 AM, Joshua Timberman < "> > wrote:
On Feb 5, 2013, at 10:54 PM, Torben Knerr < "> > wrote:

> The nagios cookbook allows to set role to search for in the search query (default is "monitoring"), but it doesn't set the role of the node, does it?
>
> If so, I wouldn't have to keep around marker roles as .rb files but would set the node's role in the application cookbook instead.
No, it only sets what the query is going to use. Essentially:

    search(:node, "role:monitoring")

Or replace with whatever the attribute gets set, e.g.:

    node.set['nagios']['server_role'] = 'nagios_thing'

Results in this query:

    search(:node, "role:nagios_thing")

> > An argument could be made that the search should be for a node with the
> > appropriate recipe applied, but only recipes in the expanded run list (not
> > those from 'include_recipe' in another recipe)...
> >
>
> Agree, but this having the problems described in 2) below...
>
> I believe that there are valid use cases for both searches, so we'd ideally find a way to handle both.
>
> > They do not get appended to the "recipes" attribute. That has also been
> > discussed in the past:
> >
> > * http://tickets.opscode.com/browse/CHEF-1977
>
> That's currently the dealbreaker for me. I added a comment and upvoted the ticket.
>
> In the meantime, is there any viable workaround other than patching the cookbooks that use search 'recipe:...'?
>
> E.g. would it be possible to set the "recipes" attribute from within the application cookbook and would that be indexed for search then?
What about using an attribute on the server set via its appropriate recipe that indicates that it is the "server" component for clients to search?

We use this in our rsyslog cookbook.

Default value:

https://github.com/opscode-cookbooks/rsyslog/blob/master/attributes/default.rb#L21

Server recipe sets the attribute:

https://github.com/opscode-cookbooks/rsyslog/blob/master/recipes/server.rb#L22

Client searches for a node with the attribute:

https://github.com/opscode-cookbooks/rsyslog/blob/master/recipes/client.rb#L25-L26

This may not require any modification of the upstream cookbook on your part either. In your "application" cookbook, have a "server" recipe that sets the attribute. In the same cookbook, have a "client" recipe that performs the search. Using the Nagios example, the "server_role" is used for the nrpe.cfg file, so you could re-open the template and set mon_host appropriately.

# recipe[my-nagios::server]
node.set['nagios']['server'] = true

# recipe[my-nagios::client]
mon_host = search(:node, "nagios_server:true")
nrpecfg = resources("template[#{node['nagios']['nrpe']['conf_dir']}/nrpe.cfg]")
nrpecfg.variables(:mon_host => mon_host)

Cheers,
Joshua





Archive powered by MHonArc 2.6.16.

§