Knife search recipe and recipes results

Chef Infra (archive)
1

Hello Chefs,

$ knife search node "recipe:nagios::server"
0 items found

$ knife search node "recipes:nagios::server"
1 items found

Node Name: nagios-new.sbni.com
Environment: production
FQDN: nagios-new.sbni.com
IP: 10.0.0.65
Run List: role[monitoring], role[munin_server], recipe[sshd::default], recipe[monit::nagios]
Roles: monitoring, munin_server, base, nagios_client
Recipes: apache2::default, network::default, nagios::server, nagios::campfire, nagios::pagerduty, monit::default, bashfire::default, monit::nagios, graphite_handler::default, ubuntu::default, build-essential::default, base_packages::default, openssl::default, chef::client, chef::notifiers, chef::delete_validation, users::sysadmins, users::root_users, sudo::default, git::default, munin::client, monit::chef_client, logrotate::default, resolver::default, sshd::default, tmux, vox_motd, static_routes::to_vpc, monit, monit::nrpe, nagios::client, munin::server, munin::f5, sbn_monitoring, nagios::check_latency_from_graphite
Platform: ubuntu 10.04
Tags:

$ knife search node "recipe:icinga::server"
1 items found

Node Name: icinga.vm
Environment: _default
FQDN: icinga.vm
IP: 10.0.2.15
Run List: recipe[apt], recipe[apache2], recipe[icinga::client], recipe[icinga::server]
Roles:
Recipes: apt, apache2, icinga::client, icinga::server
Platform: ubuntu 12.04
Tags:

$ knife search node “recipes:icinga::server”

I was aware that the recipe tag would only return recipes that are explicit in the run list.
But i was not aware that recipes would not return recipes that are in the run list. I always assumed
recipes would return all the recipes, since knife node show shows the recipes that are explicit in
the run list in the recipes tag.
The obvious fix is use using recipe*:recipename.

My question is. Why does this behave like this ? In an design perspective. I dont see any advantages.
Only confusion to what may lead to bad results. Specially if its in 3am and you are waked up by
pagerduty and you run run a knife ssh that does not cover all the machines you need.

PS: Does this apply to role and roles tag too ?

–
Regards,
Alfredo Palhares

2

On Friday, November 9, 2012 at 9:15 AM, Alfredo Palhares wrote:

Hello Chefs,

$ knife search node "recipe:nagios::server"
0 items found

$ knife search node "recipes:nagios::server"
1 items found

Node Name: nagios-new.sbni.com (http://nagios-new.sbni.com)
Environment: production
FQDN: nagios-new.sbni.com (http://nagios-new.sbni.com)
IP: 10.0.0.65
Run List: role[monitoring], role[munin_server], recipe[sshd::default], recipe[monit::nagios]
Roles: monitoring, munin_server, base, nagios_client
Recipes: apache2::default, network::default, nagios::server, nagios::campfire, nagios::pagerduty, monit::default, bashfire::default, monit::nagios, graphite_handler::default, ubuntu::default, build-essential::default, base_packages::default, openssl::default, chef::client, chef::notifiers, chef::delete_validation, users::sysadmins, users::root_users, sudo::default, git::default, munin::client, monit::chef_client, logrotate::default, resolver::default, sshd::default, tmux, vox_motd, static_routes::to_vpc, monit, monit::nrpe, nagios::client, munin::server, munin::f5, sbn_monitoring, nagios::check_latency_from_graphite
Platform: ubuntu 10.04
Tags:

$ knife search node "recipe:icinga::server"
1 items found

Node Name: icinga.vm
Environment: _default
FQDN: icinga.vm
IP: 10.0.2.15
Run List: recipe[apt], recipe[apache2], recipe[icinga::client], recipe[icinga::server]
Roles:
Recipes: apt, apache2, icinga::client, icinga::server
Platform: ubuntu 12.04
Tags:

$ knife search node "recipes:icinga::server"

I was aware that the recipe tag would only return recipes that are explicit in the run list.
But i was not aware that recipes would not return recipes that are in the run list. I always assumed
recipes would return all the recipes, since knife node show shows the recipes that are explicit in
the run list in the recipes tag.
The obvious fix is use using recipe*:recipename.

My question is. Why does this behave like this ? In an design perspective. I dont see any advantages.
Only confusion to what may lead to bad results. Specially if its in 3am and you are waked up by
pagerduty and you run run a knife ssh that does not cover all the machines you need.

PS: Does this apply to role and roles tag too ?

--
Regards,
Alfredo Palhares

It's a bit non-obvious. There's a recipes (with an "s") automatic attribute that includes all recipes from the expanded run_list (but not from include_recipe). You probably want to search on that instead.

--
Daniel DeLeo

3

Hi,

The way chef records the set of recipes and the differences between
those in the runlist, the expanded runlist and those included is an
absolute PITA. We gave up on builtin support a while ago and moved to
using a fragment like [1]. This records all the seen recipes and then
it is easy to search on that. We also use it in a similar way to this
knife plugin to audit which cookbooks are in use on which nodes etc

[1] knife-audit/lib/chef/knife/knife_audit_cookbook/recipes/default.rb at master · jbz/knife-audit · GitHub

On Sat, Nov 10, 2012 at 4:15 AM, Alfredo Palhares
masterkorp@masterkorp.net wrote:

Hello Chefs,

$ knife search node "recipe:nagios::server"
0 items found

$ knife search node "recipes:nagios::server"
1 items found

Node Name: nagios-new.sbni.com
Environment: production
FQDN: nagios-new.sbni.com
IP: 10.0.0.65
Run List: role[monitoring], role[munin_server], recipe[sshd::default], recipe[monit::nagios]
Roles: monitoring, munin_server, base, nagios_client
Recipes: apache2::default, network::default, nagios::server, nagios::campfire, nagios::pagerduty, monit::default, bashfire::default, monit::nagios, graphite_handler::default, ubuntu::default, build-essential::default, base_packages::default, openssl::default, chef::client, chef::notifiers, chef::delete_validation, users::sysadmins, users::root_users, sudo::default, git::default, munin::client, monit::chef_client, logrotate::default, resolver::default, sshd::default, tmux, vox_motd, static_routes::to_vpc, monit, monit::nrpe, nagios::client, munin::server, munin::f5, sbn_monitoring, nagios::check_latency_from_graphite
Platform: ubuntu 10.04
Tags:

$ knife search node "recipe:icinga::server"
1 items found

Node Name: icinga.vm
Environment: _default
FQDN: icinga.vm
IP: 10.0.2.15
Run List: recipe[apt], recipe[apache2], recipe[icinga::client], recipe[icinga::server]
Roles:
Recipes: apt, apache2, icinga::client, icinga::server
Platform: ubuntu 12.04
Tags:

$ knife search node "recipes:icinga::server"

I was aware that the recipe tag would only return recipes that are explicit in the run list.
But i was not aware that recipes would not return recipes that are in the run list. I always assumed
recipes would return all the recipes, since knife node show shows the recipes that are explicit in
the run list in the recipes tag.
The obvious fix is use using recipe*:recipename.

My question is. Why does this behave like this ? In an design perspective. I dont see any advantages.
Only confusion to what may lead to bad results. Specially if its in 3am and you are waked up by
pagerduty and you run run a knife ssh that does not cover all the machines you need.

PS: Does this apply to role and roles tag too ?

--
Regards,
Alfredo Palhares

--
Cheers,

Peter Donald

4

Seems like it would be easy to always include seen_recipes in the search
resultsŠ

Adam

On 11/9/12 3:28 PM, "Peter Donald" peter@realityforge.org wrote:

Hi,

The way chef records the set of recipes and the differences between
those in the runlist, the expanded runlist and those included is an
absolute PITA. We gave up on builtin support a while ago and moved to
using a fragment like [1]. This records all the seen recipes and then
it is easy to search on that. We also use it in a similar way to this
knife plugin to audit which cookbooks are in use on which nodes etc

[1]
https://github.com/jbz/knife-audit/blob/master/lib/chef/knife/knife_audit_
cookbook/recipes/default.rb

On Sat, Nov 10, 2012 at 4:15 AM, Alfredo Palhares
masterkorp@masterkorp.net wrote:

Hello Chefs,

$ knife search node "recipe:nagios::server"
0 items found

$ knife search node "recipes:nagios::server"
1 items found

Node Name: nagios-new.sbni.com
Environment: production
FQDN: nagios-new.sbni.com
IP: 10.0.0.65
Run List: role[monitoring], role[munin_server],
recipe[sshd::default], recipe[monit::nagios]
Roles: monitoring, munin_server, base, nagios_client
Recipes: apache2::default, network::default, nagios::server,
nagios::campfire, nagios::pagerduty, monit::default, bashfire::default,
monit::nagios, graphite_handler::default, ubuntu::default,
build-essential::default, base_packages::default, openssl::default,
chef::client, chef::notifiers, chef::delete_validation,
users::sysadmins, users::root_users, sudo::default, git::default,
munin::client, monit::chef_client, logrotate::default,
resolver::default, sshd::default, tmux, vox_motd, static_routes::to_vpc,
monit, monit::nrpe, nagios::client, munin::server, munin::f5,
sbn_monitoring, nagios::check_latency_from_graphite
Platform: ubuntu 10.04
Tags:

$ knife search node "recipe:icinga::server"
1 items found

Node Name: icinga.vm
Environment: _default
FQDN: icinga.vm
IP: 10.0.2.15
Run List: recipe[apt], recipe[apache2], recipe[icinga::client],
recipe[icinga::server]
Roles:
Recipes: apt, apache2, icinga::client, icinga::server
Platform: ubuntu 12.04
Tags:

$ knife search node "recipes:icinga::server"

I was aware that the recipe tag would only return recipes that are
explicit in the run list.
But i was not aware that recipes would not return recipes that are in
the run list. I always assumed
recipes would return all the recipes, since knife node show shows the
recipes that are explicit in
the run list in the recipes tag.
The obvious fix is use using recipe*:recipename.

My question is. Why does this behave like this ? In an design
perspective. I dont see any advantages.
Only confusion to what may lead to bad results. Specially if its in 3am
and you are waked up by
pagerduty and you run run a knife ssh that does not cover all the
machines you need.

PS: Does this apply to role and roles tag too ?

--
Regards,
Alfredo Palhares

--
Cheers,

Peter Donald