Name field search matching differs for OS::Nova::Server than it does for other resource types

[Travis Tripp]

Using searchlight UI or python CLI, you will get different results when searching on the name field between OS::Nova::Server and other types. In my system, I have multiple instances and other types that have names which start with demo and end with _1, _2, _3. typing just demo returns instance results but does not return other resources. demo* will return the other types.

UI: http://imgur.com/a/3httH

CLI:

ttripp@ubuntu:~$ openstack
(openstack) search query "demo"
+--------------------------------------+--------+-----------+------------------+----------------------+
| ID | Name | Score | Type | Updated |
+--------------------------------------+--------+-----------+------------------+----------------------+
| bb90d5b3-1513-4dcf-a427-fc95aaaaba5c | demo_3 | 0.5239726 | OS::Nova::Server | 2016-08-29T16:03:54Z |
| e9fa0313-d190-49fe-bc8e-e0b29dba024d | demo_2 | 0.5239726 | OS::Nova::Server | 2016-08-29T20:49:43Z |
| 4e032829-db32-42d3-855b-05dd0e944ece | demo_1 | 0.5239726 | OS::Nova::Server | 2016-08-29T20:50:09Z |
| 78ca20a0-4d42-43e6-8ae9-4025b188a73b | demo_4 | 0.5239726 | OS::Nova::Server | 2016-08-29T20:49:16Z |
+--------------------------------------+--------+-----------+------------------+----------------------+
(openstack) search query "demo*"
+--------------------------------------+--------------------+-------+--------------------------+----------------------------+
| ID | Name | Score | Type | Updated |
+--------------------------------------+--------------------+-------+--------------------------+----------------------------+
| 2af7a05a-dda0-4373-beb9-ad5a99346140 | demo_3 | 1.0 | OS::Cinder::Volume | 2016-08-25T18:45:24.000000 |
| fa10badc-d87d-49c7-8f4b-512744ac17f1 | demo_2 | 1.0 | OS::Cinder::Volume | 2016-08-25T18:44:38.000000 |
| 9564388c-dd99-4f93-a9ba-db3c3580717b | demo_1 | 1.0 | OS::Cinder::Volume | 2016-08-25T18:43:53.000000 |
| dc3db1e1-ae67-41e5-9701-c2a54fad1a98 | demo_1 | 1.0 | OS::Glance::Image | 2016-08-25T18:43:50Z |
| 222b25fb-899b-4951-aa20-5f9a2d043ab5 | demo_1.demo_1. | 1.0 | OS::Designate::RecordSet | 2016-08-25T18:44:19.000000 |
| aa45857e-78d6-4f82-b109-98a6c678ed48 | demo_1.demo_1. | 1.0 | OS::Designate::RecordSet | 2016-08-25T18:43:54.000000 |
| e6117646-7a6d-4653-b526-ce205f2b94e9 | www.demo_1.demo_1. | 1.0 | OS::Designate::RecordSet | 2016-08-25T18:44:19.000000 |
| b0c718f8-61d9-447b-8beb-863985ec4a7f | demo_2.demo_2. | 1.0 | OS::Designate::RecordSet | 2016-08-25T18:44:40.000000 |
| d157e233-3827-453e-a8b2-ba16fdf17b2b | demo_2.demo_2. | 1.0 | OS::Designate::RecordSet | 2016-08-25T18:45:04.000000 |
| 09f5d851-dfb0-4881-bd5e-dced0733d21a | www.demo_2.demo_2. | 1.0 | OS::Designate::RecordSet | 2016-08-25T18:45:04.000000 |
| 45930823-bf1c-48df-a4ab-c6fa65e55e7a | demo_3.demo_3. | 1.0 | OS::Designate::RecordSet | 2016-08-25T18:45:25.000000 |
| e8f603d7-1949-4cfd-8ac8-611a2ccd501f | demo_3.demo_3. | 1.0 | OS::Designate::RecordSet | 2016-08-25T18:45:38.000000 |
| 7b3d41ac-a2a3-4b50-b428-d8acc95c8c51 | www.demo_3.demo_3. | 1.0 | OS::Designate::RecordSet | 2016-08-25T18:45:37.000000 |
| 31c6a233-ed29-4c74-990e-80b8dda8b73d | demo_25 | 1.0 | OS::Glance::Image | 2016-08-25T18:51:59.000000 |
| e84bd8ab-85ae-4c70-8016-4a0e4a7b0b82 | demo_3 | 1.0 | OS::Glance::Image | 2016-08-25T22:41:04Z |
| 707873fb-7f8f-453d-9688-00246f9727bd | demo_4 | 1.0 | OS::Glance::Image | 2016-08-26T16:57:20.000000 |
| bb90d5b3-1513-4dcf-a427-fc95aaaaba5c | demo_3 | 1.0 | OS::Nova::Server | 2016-08-29T16:03:54Z |
| e9fa0313-d190-49fe-bc8e-e0b29dba024d | demo_2 | 1.0 | OS::Nova::Server | 2016-08-29T20:49:43Z |
| 4e032829-db32-42d3-855b-05dd0e944ece | demo_1 | 1.0 | OS::Nova::Server | 2016-08-29T20:50:09Z |
| 78ca20a0-4d42-43e6-8ae9-4025b188a73b | demo_4 | 1.0 | OS::Nova::Server | 2016-08-29T20:49:16Z |
| b4604e32-cb04-442b-926a-917799a53ae5 | demo_1.demo_1. | 1.0 | OS::Designate::Zone | 2016-08-25T18:44:39.000000 |
| 4cb547d0-bacb-4ef8-ba48-53968f4a51a8 | demo_2.demo_2. | 1.0 | OS::Designate::Zone | 2016-08-25T18:45:24.000000 |
| 047b1cdf-c007-4971-a188-75f808f91004 | demo_3.demo_3. | 1.0 | OS::Designate::Zone | 2016-08-25T18:45:58.000000 |
+--------------------------------------+--------------------+-------+--------------------------+----------------------------+
(openstack)

[Steve McLellan (sjmc7)]

Are those instances matching on something other than 'name'?

I think you're seeing the effect of the default tokenizer; the unicode standard that the default analyzer uses for splitting words doesn't include underscores in its word boundary list. If you create an instance 'demo-1' (dash) then you'll see a search for 'demo' return it but not an instance named 'demo_1'.

Arguably we should change the analyzer to include underscores. This might be considered an example of https://bugs.launchpad.net/searchlight/+bug/1602718

[Steve McLellan (sjmc7)]

The question here is what we want the behavior to be - for servers with names "demo-1" and "demo_1" do you want a search for "name:demo" to return both of them (meaning we'd use both dashes and underscores as word delimiters) or neither (meaning we'd use neither), or maintain the current behavior (matching "demo-1"). For reasons I'm mysteriously unable to fathom, underscore has long been treated as a 'word' character going back to the origins of regex which perhaps explains the default unicode tokenizer behavior. Note that a wildcard search for 'demo*' would return both, and we do still maintain a field called name.raw that contains the un-tokenized string.