[chef] Re: Re: Weird search behavior, need advice

[Chris Sibbitt < >]

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

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

P: 613.686.1590 " style="color:rgb(17,85,204)" target="_blank">