Bug 1797717 - Search backend cannot find VMs which name starts with a search keyword
Summary: Search backend cannot find VMs which name starts with a search keyword
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.3.7
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ovirt-4.4.3
: 4.4.3
Assignee: Eli Mesika
QA Contact: Ivana Saranova
URL:
Whiteboard:
Depends On: 1431882
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-03 17:52 UTC by Ameya Charekar
Modified: 2024-03-25 15:40 UTC (History)
12 users (show)

Fixed In Version: rhv-4.4.3-3
Doc Type: Enhancement
Doc Text:
With this enhancement, you can now perform a free text search in the Administration Portal for entity names that begin with internally defined keywords.
Clone Of: 1431882
Environment:
Last Closed: 2020-11-24 13:09:18 UTC
oVirt Team: Infra
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 4818711 0 None None None 2020-02-11 13:56:36 UTC
Red Hat Product Errata RHSA-2020:5179 0 None None None 2020-11-24 13:10:34 UTC
oVirt gerrit 111173 0 master MERGED search: enable to search with keyword prefix 2021-02-10 05:43:50 UTC

Comment 2 Martin Perina 2020-02-11 15:46:46 UTC
Ameya as mentioned in upstream bug you need to use 'name' identifier when searching for VMs which name starts with predefined keyword: https://bugzilla.redhat.com/show_bug.cgi?id=1431882#c10

In your example:

  Vms: name=osp*

Above should work and return all VMs with name starting with 'osp' prefix.

But below will not work:

  Vms: osp*
  Vms: osp

and both will always return empty list because 'os' is predefined keyword. You can find list of all existing predefined keywords in https://bugzilla.redhat.com/show_bug.cgi?id=1431882#c8

Could you please confirm with customer that search using 'name' identifier works as expected?

Comment 3 Logan Kuhn 2020-02-11 15:48:52 UTC
I'm the customer.  It doesn't work as expected.  Expected is to search for Vms: osw and find hosts that contain the string osw.

Comment 4 Martin Perina 2020-02-11 15:51:45 UTC
(In reply to Logan Kuhn from comment #3)
> I'm the customer.  It doesn't work as expected.  Expected is to search for
> Vms: osw and find hosts that contain the string osw.

So could you please use the full name format:

  Vms: name=osw*

Comment 5 Logan Kuhn 2020-02-11 16:04:18 UTC
Yes that works, but it's not the slightest bit intuitive and presents like a bug in the interface.

If an administrator is evaluating ovirt or rhev for production use, types in the name of a system starting with a keyword (Vms: osw) and finds zero results even though the guest exists, what impression is that going to give them?  It's the first thing someone is going to do and it doesn't work.

I can understand the amount of work it'd take to rewrite a search interface and I don't envy the task.  However, could there be something to make it more intuitive?  for example Vms: osw has a pop up that says "Did you mean: Vms: name=osw?"  With a link to the corresponding documentation explaining the convenience of using keywords.  It'd be a simply little pop up and that capability is already integrated into the product with Patternfly.

Comment 8 Sandro 2020-03-03 15:22:51 UTC
Hello,

i would also vote for at least a pop-up as we have the exact same issue and most of my colleagues are used to just typing 'foo' in the search bar and they get a list of all servers starting with foo.
Now with osp this changes and they should at least get a pop-up saying did u mean name=osp* .

Comment 12 Logan Kuhn 2020-09-14 12:24:19 UTC
Thank you for all the hardwork that went into this.

Comment 15 Ivana Saranova 2020-10-02 23:23:24 UTC
Steps:
1) Create an instance (VM, disk,...) that starts with special keyword (id, os, vm_names,...), for example VM 'idempiere'
2) Search for that instance:
     a) using only the keyword (Vms: id)
        - nothing is returned
     b) keyword + any characters (Vms: id*)
        - correct VM is returned
     c) keyword + additional characters from the instance's name (Vms: idem)
        - correct VM is returned
     d) using attribute with only keyword (Vms: name=id)
        - nothing is returned
     e) using attribute with keyword + any characters (Vms: name=id*)
        - correct VM is returned

Results:
Search engine is behaving correctly limited only by the sole keywords.

Verified in:
ovirt-engine-4.4.3.5-0.5.el8ev.noarch

Comment 16 Logan Kuhn 2020-10-05 12:50:19 UTC
Thank you!!!

Any chance this could get back ported to 4.3?  I ask because my company isn't upgrading to 4.4 until next year.

Comment 17 Martin Perina 2020-10-06 12:26:22 UTC
(In reply to Logan Kuhn from comment #16)
> Thank you!!!
> 
> Any chance this could get back ported to 4.3?  I ask because my company
> isn't upgrading to 4.4 until next year.

No, RHV 4.3.11 has already been released and it was the last RHV Manager 4.3.z release.

Comment 18 Eli Marcus 2020-11-22 16:51:36 UTC
Hi Eli, 
please review this doc text for the errata:
 
With this enhancement, you can now perform a free text search in the Administration Portal that includes internally defined keywords.

Comment 22 errata-xmlrpc 2020-11-24 13:09:18 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Low: Red Hat Virtualization security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:5179

Comment 23 Eli Mesika 2020-11-29 07:41:47 UTC
(In reply to Eli Marcus from comment #18)
> Hi Eli, 
> please review this doc text for the errata:
>  
> With this enhancement, you can now perform a free text search in the
> Administration Portal that includes internally defined keywords.

"that includes" => "that starts with"


Note You need to log in before you can comment on or make changes to this bug.