chef/chef-server

Chef Client Range Search Unexpected Results

sean-horn opened this issue · 4 comments

sean-horn commented

Description

On Chef Client 17.9.26 and 17.4.38, I can reproduce a faulty match with a simple knife range search

Chef Version

17.4.38 and 17.9.26

Platform Version

RHEL 8

Replication Case

  • I install a chef workstation that has Chef Client 17.9.26
  • Next, I create a node in Hosted Chef named mytestnode
  • Now, try to query the node by the uptime_seconds attribute. It only has one of these.
  • It appears the matching in the range is not occurring on all characters in the range, but only the first or first several
  • It seems a bug that an uptime_seconds value of 702667 is matched with an end of range of 72

Client Output

$ knife --version
Chef Infra Client: 17.9.26

MCWFHHORN$ knife node show mytestnode -l -Fjson | grep uptime_seconds
    "uptime_seconds": 702667,

MCWFHHORN$ knife search 'uptime_seconds:[0 TO 72]'

1 items found

Node Name:   mytestnode
Environment: _default
FQDN:
IP:          192.168.1.7
Run List:    recipe[test1]
Roles:
Recipes:     test1, test1::default
Platform:    mac_os_x 11.5.2
Tags:

MCWFHHORN$ knife search 'uptime_seconds:[0 TO 70]'

0 items found

# Getting really weird now and it still returns a hit when it should not
MCWFHHORN$ $ knife search node 'uptime_seconds:[0 TO 7222]' -a uptime_seconds

1 items found

mytestnode:
  uptime_seconds: 702667
lamont-granquist commented

This is probably a bug against server? We just feed the solr search syntax to the chef-server and get back its results.

vkarve-chef commented

This appears to an issue on chef-server. i could reproduce the issue with same pattern fed in the Chef Manage Nodes search field.

in4mer commented

@sean-horn Should I open another issue on chef-server, or would it be better to wait?

PrajaktaPurohit commented

https://chefio.atlassian.net/browse/CHEF-648 : Closing as will not implement.

Copying over the relevant comments:
@sreepuramsudheer :
Node data is stored as string so integer comparison can’t be performed.
There are two potential solutions to enable numerical comparison. introduce a parallel index for number fields.
fetch the nodes from database for special queries.
We are exploring the feasibility of these and will update the progress.

The current method of storing indices on infra server is using string structures, that does not let us execute numeric comparisons on the integer values. In order to support this feature, we will nee to change the indices and the internals of how search works on Infra Server.

@PrajaktaPurohit:
The mismatch seen in the searches related to ranges have to do with how the data gets stored in the Index. The objects in the search index are stored as strings and the search expects to operate on integers and hence we see the inconsistent data. There might be a couple of different ways to fix this, however none of them would be trivial. This is not currently prioritized for the Infra Server team until August 2023.

Product:
closing this for now since it requires making some fundamental changes to how we store data. Kindly reopen if this becomes a blocker for any of our customers