Knife search cookbook/recipe

We noticed some strangeness in our search results when using a cookbook
name and dropping the implied ‘default’ recipe. I wonder if anyone else
has seen this or if it’s documented somewhere?

Our understanding is that “cookbook::default” and “cookbook” are
functionally identical strings and that substitution happens in some
magical place inside the bowels of chef. But this is not the case, to wit:

node1 and node2 both have “foobar” in their run_list, the “::default” is
implied for both but not included in the node definition from what I can
see.

When I do a “knife node show …” on node1, I see in Recipes that the Chef
server has recorded “foobar::default”. On node2, it just shows “foobar”.

When I use search like this - “knife search node ‘recipes:foobar’”, the
only result returned is node2.

This search term returns both node1 and node2 - “knife search node
’recipes:foobar::default’”

This seems to be an inconsistency in how our Chef Server is recording new
nodes (unevenly adding “default” to some cookbook names specified in the
run_list), as well as how the “recipes” filter returns results in Search.

Can anyone point me to some documentation on how to make node creation and
search more consistent without auditing my entire environment and adding
"::default" everywhere it’s implied?

Greg Damiani | BuzzFeed | Senior System Administrator | @grggls

40 Argyll Street, 2nd Floor, London, W1F 7EB

Hey, this was probably related to https://github.com/chef/chef/pull/4003, which will be fixed in 12.5, coming soon.

The TLDR is that we tried to clean up the saved list of recipes to be expanded, ie foo::default in the 12.2 client - however a lot of people, like you, wrote their searches to just look for foo. So now we’ll save both the unexpanded and the expanded version, and then probably in 13 we’ll move forward to just saving the expanded version again.

Hope this helps, -Thom

– Thom May

On 5 October 2015 at 18:57:26, Greg Damiani (greg.damiani@buzzfeed.com) wrote:

We noticed some strangeness in our search results when using a cookbook name and dropping the implied ‘default’ recipe. I wonder if anyone else has seen this or if it’s documented somewhere?

Our understanding is that “cookbook::default” and “cookbook” are functionally identical strings and that substitution happens in some magical place inside the bowels of chef. But this is not the case, to wit:

node1 and node2 both have “foobar” in their run_list, the “::default” is implied for both but not included in the node definition from what I can see.

When I do a “knife node show …” on node1, I see in Recipes that the Chef server has recorded “foobar::default”. On node2, it just shows “foobar”.

When I use search like this - “knife search node ‘recipes:foobar’”, the only result returned is node2.

This search term returns both node1 and node2 - “knife search node ‘recipes:foobar::default’”

This seems to be an inconsistency in how our Chef Server is recording new nodes (unevenly adding “default” to some cookbook names specified in the run_list), as well as how the “recipes” filter returns results in Search.

Can anyone point me to some documentation on how to make node creation and search more consistent without auditing my entire environment and adding “::default” everywhere it’s implied?

Greg
Damiani
|
BuzzFeed
|
Senior System Administrator
| @grggls

40 Argyll Street, 2nd Floor, London, W1F 7EB

It might also be related to the prior bug which would return 'foo' in
some cases and 'foo::default' in others. It was inconsistent, which is
why I fixed it to 'foo::default' to be consistent.

I'm actually kinda 'meh' on changing the behavior in 13, it seems like
12.5 will be consistent and usable and back-compat, and i'm not sure
having both will hurt anyone...

On 10/05/2015 11:15 AM, Thom May wrote:

Hey, this was probably related to
Ensure that our list of recipes is backwards compat by thommay · Pull Request #4003 · chef/chef · GitHub, which will be fixed in 12.5,
coming soon.

The TLDR is that we tried to clean up the saved list of recipes to be
expanded, ie |foo::default| in the 12.2 client - however a lot of
people, like you, wrote their searches to just look for |foo|. So now
we’ll save both the unexpanded and the expanded version, and then
probably in 13 we’ll move forward to just saving the expanded version
again.

Hope this helps, -Thom

– Thom May

On 5 October 2015 at 18:57:26, Greg Damiani (greg.damiani@buzzfeed.com
mailto:greg.damiani@buzzfeed.com) wrote:

We noticed some strangeness in our search results when using a
cookbook name and dropping the implied 'default' recipe. I wonder if
anyone else has seen this or if it's documented somewhere?

Our understanding is that "cookbook::default" and "cookbook" are
functionally identical strings and that substitution happens in some
magical place inside the bowels of chef. But this is not the case,
to wit:

node1 and node2 both have "foobar" in their run_list, the "::default"
is implied for both but not included in the node definition from what
I can see.

When I do a "knife node show ..." on node1, I see in Recipes that the
Chef server has recorded "foobar::default". On node2, it just shows
"foobar".

When I use search like this - "knife search node 'recipes:foobar'",
the only result returned is node2.

This search term returns both node1 and node2 - "knife search node
'recipes:foobar::default'"

This seems to be an inconsistency in how our Chef Server is recording
new nodes (unevenly adding "default" to some cookbook names specified
in the run_list), as well as how the "recipes" filter returns results
in Search.

Can anyone point me to some documentation on how to make node
creation and search more consistent without auditing my entire
environment and adding "::default" everywhere it's implied?

--

Greg Damiani | BuzzFeed | Senior System Administrator | @grggls

40 Argyll Street, 2nd Floor, London, W1F 7EB

Thanks for the fast response. Always great to hear you folks are one step
ahead in terms of fixing these things.

On Mon, Oct 5, 2015 at 11:29 AM, Lamont Granquist lamont@chef.io wrote:

It might also be related to the prior bug which would return 'foo' in some
cases and 'foo::default' in others. It was inconsistent, which is why I
fixed it to 'foo::default' to be consistent.

I'm actually kinda 'meh' on changing the behavior in 13, it seems like
12.5 will be consistent and usable and back-compat, and i'm not sure having
both will hurt anyone...

On 10/05/2015 11:15 AM, Thom May wrote:

Hey, this was probably related to Ensure that our list of recipes is backwards compat by thommay · Pull Request #4003 · chef/chef · GitHub,
which will be fixed in 12.5, coming soon.

The TLDR is that we tried to clean up the saved list of recipes to be
expanded, ie foo::default in the 12.2 client - however a lot of people,
like you, wrote their searches to just look for foo. So now we’ll save
both the unexpanded and the expanded version, and then probably in 13 we’ll
move forward to just saving the expanded version again.

Hope this helps, -Thom

– Thom May

On 5 October 2015 at 18:57:26, Greg Damiani (greg.damiani@buzzfeed.com)
wrote:

We noticed some strangeness in our search results when using a cookbook
name and dropping the implied 'default' recipe. I wonder if anyone else
has seen this or if it's documented somewhere?

Our understanding is that "cookbook::default" and "cookbook" are
functionally identical strings and that substitution happens in some
magical place inside the bowels of chef. But this is not the case, to wit:

node1 and node2 both have "foobar" in their run_list, the "::default" is
implied for both but not included in the node definition from what I can
see.

When I do a "knife node show ..." on node1, I see in Recipes that the Chef
server has recorded "foobar::default". On node2, it just shows "foobar".

When I use search like this - "knife search node 'recipes:foobar'", the
only result returned is node2.

This search term returns both node1 and node2 - "knife search node
'recipes:foobar::default'"

This seems to be an inconsistency in how our Chef Server is recording new
nodes (unevenly adding "default" to some cookbook names specified in the
run_list), as well as how the "recipes" filter returns results in Search.

Can anyone point me to some documentation on how to make node creation and
search more consistent without auditing my entire environment and adding
"::default" everywhere it's implied?

--

Greg Damiani | BuzzFeed | Senior System Administrator | @grggls

40 Argyll Street, 2nd Floor, London, W1F 7EB

--

Greg Damiani | BuzzFeed | Senior System Administrator | @grggls

40 Argyll Street, 2nd Floor, London, W1F 7EB

I have a syntax problem where I'm trying to perform a knife search across all the nodes to find a cookbook in the run_list but I also want to print the version of the cookbook. I can search all the nodes for the cookbook but haven't come across a way to have the query report the different versions running on each node. Any suggestions

maybe the -a flag? I don't know when this started getting tracked - which chef-client version, this is a new test host i'm working on with 15.5.17 - but each individual cookbook has a subattribute for version you can access with the dot-notation.

$ knife search node cookbooks:git -a cookbooks.git.version
1 items found

ip-172-31-90-158.ec2.internal:
cookbooks.git.version: 10.0.0