# Weird search behavior, need advice

**URL:** <https://discourse.chef.io/t/weird-search-behavior-need-advice/6595>\
**Category:** Chef Infra (archive)\
**Created:** [May 18, 2015, 7:15pm UTC](https://discourse.chef.io/t/weird-search-behavior-need-advice/6595 "2015-05-18T19:15:13Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jordan\_Wesolowski](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jordan_wesolowski/32/80_2.png) [@Jordan\_Wesolowski](https://discourse.chef.io/u/Jordan_Wesolowski)\
**Post date:** [May 18, 2015, 7:15pm UTC](https://discourse.chef.io/t/weird-search-behavior-need-advice/6595/1 "2015-05-18T19:15:13Z")

</div>

Hello Chef Community,

I’ve noticed an interesting problem with searching that has to do with the behavior of SOLR. Normally, when looking for nodes that are in the same Chef environment, we would do something like this:

search(:node, “chef\_environment:#{node.chef\_environment}”)

Unfortunately, SOLR will pick up a node in a different environment if it has a nested attribute with the same name. So for example, a node has:

node.set[‘break’][‘search’][‘with’][‘chef\_environment’] = ‘production'

That node would show up in search results looking for production nodes regardless of its actual chef environment.

I whipped together a quick example with tests here:

> **[jrwesolo/chef\_search\_woes](https://github.com/jrwesolo/chef_search_woes)**
>
> Contribute to jrwesolo/chef\_search\_woes development by creating an account on GitHub.

A fix will cause all the tests to pass. I have an example fix in a comment of the default recipe, but I was hoping for a solution that was a little more elegant.

Does anyone have any advice on a better way to do this? I use chef\_environment and ipaddress as examples in the cookbook, but it could be any other attribute that happens to conflict due to nesting.

Sincerely,  
Jordan Wesolowski

---

<div class="post-metadata">

**Author:** ![Justin\_Dossey](https://avatars.discourse-cdn.com/v4/letter/j/e19b73/32.png) [@Justin\_Dossey](https://discourse.chef.io/u/Justin_Dossey)\
**Post date:** [May 19, 2015, 5:48pm UTC](https://discourse.chef.io/t/weird-search-behavior-need-advice/6595/2 "2015-05-19T17:48:41Z")

</div>

This is actually a huge deal!

If attribute names are indexed in a flat namespace, then any node in any  
environment could break any cookbook that uses search for top-level  
attributes.

We have no way to specify the "absolute path" to a top level attribute, so  
deeply-nested attributes take the same precedence as top-level ones.

Therefore, we can't trust any search result from a query using top-level  
attributes.

On Mon, May 18, 2015 at 12:15 PM, Jordan Wesolowski [jrwesolo@gmail.com](mailto:jrwesolo@gmail.com)  
wrote:

> Hello Chef Community,
> 
> I’ve noticed an interesting problem with searching that has to do with the  
> behavior of SOLR. Normally, when looking for nodes that are in the same  
> Chef environment, we would do something like this:
> 
> search(:node, “chef\_environment:#{node.chef\_environment}”)
> 
> Unfortunately, SOLR will pick up a node in a different environment if it  
> has a nested attribute with the same name. So for example, a node has:
> 
> node.set[‘break’][‘search’][‘with’][‘chef\_environment’] = ‘production'
> 
> That node would show up in search results looking for production nodes  
> regardless of its actual chef environment.
> 
> I whipped together a quick example with tests here:  
> [GitHub - jrwesolo/chef\_search\_woes](https://github.com/jrwesolo/chef_search_woes)
> 
> A fix will cause all the tests to pass. I have an example fix in a comment  
> of the default recipe, but I was hoping for a solution that was a little  
> more elegant.
> 
> Does anyone have any advice on a better way to do this? I use  
> chef\_environment and ipaddress as examples in the cookbook, but it could be  
> any other attribute that happens to conflict due to nesting.
> 
> Sincerely,  
> Jordan Wesolowski

--  
Justin Dossey  
Practice Owner  
New Context Services, Inc

---

<div class="post-metadata">

**Author:** ![Chris\_Sibbitt](https://avatars.discourse-cdn.com/v4/letter/c/6bbea6/32.png) [@Chris\_Sibbitt](https://discourse.chef.io/u/Chris_Sibbitt)\
**Post date:** [July 24, 2015, 7:34pm UTC](https://discourse.chef.io/t/weird-search-behavior-need-advice/6595/3 "2015-07-24T19:34:03Z")

</div>

We ran into this recently as well, our "solution" (it's not, really) was to  
move the attribute into a more specific namespace, so instead of  
node['zone'] we had node['ourbasecookbook']['zone']. Searching on  
ourbasecookbook\_zone is way less likely to run into a conflict, but  
ultimately feels like kicking the can. I would also like to see a way to  
match on an "absolute path"

On Tue, May 19, 2015 at 1:48 PM, Justin Dossey \<[justin.dossey@newcontext.com](mailto:justin.dossey@newcontext.com)

> wrote:

> This is actually a huge deal!
> 
> If attribute names are indexed in a flat namespace, then any node in any  
> environment could break any cookbook that uses search for top-level  
> attributes.
> 
> We have no way to specify the "absolute path" to a top level attribute, so  
> deeply-nested attributes take the same precedence as top-level ones.
> 
> Therefore, we can't trust any search result from a query using top-level  
> attributes.
> 
> On Mon, May 18, 2015 at 12:15 PM, Jordan Wesolowski [jrwesolo@gmail.com](mailto:jrwesolo@gmail.com)  
> wrote:
> 
> > Hello Chef Community,
> > 
> > I’ve noticed an interesting problem with searching that has to do with  
> > the behavior of SOLR. Normally, when looking for nodes that are in the same  
> > Chef environment, we would do something like this:
> > 
> > search(:node, “chef\_environment:#{node.chef\_environment}”)
> > 
> > Unfortunately, SOLR will pick up a node in a different environment if it  
> > has a nested attribute with the same name. So for example, a node has:
> > 
> > node.set[‘break’][‘search’][‘with’][‘chef\_environment’] = ‘production'
> > 
> > That node would show up in search results looking for production nodes  
> > regardless of its actual chef environment.
> > 
> > I whipped together a quick example with tests here:  
> > [GitHub - jrwesolo/chef\_search\_woes](https://github.com/jrwesolo/chef_search_woes)
> > 
> > A fix will cause all the tests to pass. I have an example fix in a  
> > comment of the default recipe, but I was hoping for a solution that was a  
> > little more elegant.
> > 
> > Does anyone have any advice on a better way to do this? I use  
> > chef\_environment and ipaddress as examples in the cookbook, but it could be  
> > any other attribute that happens to conflict due to nesting.
> > 
> > Sincerely,  
> > Jordan Wesolowski
> 
> --  
> Justin Dossey  
> Practice Owner  
> New Context Services, Inc

--

## _Chris Sibbitt_ | _Infrastructure Systems Architect_

[WWW.THINKINGPHONES.COM](http://WWW.THINKINGPHONES.COM)  
[http://www.thinkingphones.com/](http://www.thinkingphones.com/)

P: 613.686.1590  
[CSIBBITT@THINKINGPHONES.COM](mailto:CSIBBITT@THINKINGPHONES.COM) [http://www.thinkingphones.com/](http://www.thinkingphones.com/)[image:  
LinkedIn] [http://www.linkedin.com/company/thinking-phone-networks](http://www.linkedin.com/company/thinking-phone-networks)[image:  
facebook] [https://www.facebook.com/thinkingphones](https://www.facebook.com/thinkingphones)  
[http://www.linkedin.com/company/thinking-phone-networks](http://www.linkedin.com/company/thinking-phone-networks)[image: Twitter]  
[https://twitter.com/thinkingphones](https://twitter.com/thinkingphones)[image: RSS Feed]  
[http://thinkingphones.com/feed/](http://thinkingphones.com/feed/)