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

[Torben Knerr < >]

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 < " target="_blank"> > 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