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
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
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
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
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
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
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
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
http://www.thinkingphones.com/
P: 613.686.1590
CSIBBITT@THINKINGPHONES.COM http://www.thinkingphones.com/[image:
LinkedIn] http://www.linkedin.com/company/thinking-phone-networks[image:
facebook] https://www.facebook.com/thinkingphones
http://www.linkedin.com/company/thinking-phone-networks[image: Twitter]
https://twitter.com/thinkingphones[image: RSS Feed]
http://thinkingphones.com/feed/