[chef] Re: Weird search behavior, need advice


Chronological Thread 
  • From: Justin Dossey < >
  • To:
  • Subject: [chef] Re: Weird search behavior, need advice
  • Date: Tue, 19 May 2015 10:48:41 -0700

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:

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



Archive powered by MHonArc 2.6.16.

§