+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1513398 +++ ====================================================================== Description of problem: rhv manager does not show the results of the search properly Version-Release number of selected component (if applicable): 4.1.6 How reproducible: always Steps to Reproduce: Search on a given attribute gives the expected result (ie. list of all VMs having this attribute set on this value). But when an attribute is empty, the associated VM does not appear ever in the results of a research. Example with 3 VMs: - VM1 with attribute comment foo - VM2 with attribute comment bar - VM3 without attribute comment (attribute empty) When we do the following research: - Vms: comment = foo => gives VM1 - Vms: comment != foo => gives VM2 (but not VM3 !) - Vms: comment = "" => does not give anything - Vms: comment != "" => gives VM1 and VM2 Actual results: search does not include vms when comment attribute is empty Expected results: search will include vms when comment attribute is empty Additional info: it is working with "Vms: description =/!=" as expected (Originally by Marian Jankular)
It is an issue in BaseConditionFieldAutoCompleter. There were some fixes around this area in 4.2 but Im not sure it will handle also this case: https://bugzilla.redhat.com/show_bug.cgi?id=1252906 https://bugzilla.redhat.com/show_bug.cgi?id=1454821 Moving to infra to make sure. (Originally by Tomas Jelinek)
The bug was by mistake merged too soon, so it's already present in 4.1.8 RC4 build
The same problem in VMs is with custom_cpu_type != conroe custom_emulated_machine != q35 host != vhost02 (not sure that this should really show VMs that are not running on any host, from my point of view yes) in Storage (same with Storages.xx in VMs) description = "" comment = "" And there could be more in other items. Is there not a way how to fix all processing of null values at once?
tested in ovirt-engine-4.1.8.2-0.1.el7.noarch
Moving to 4.1.9 until resolved the scope of BZ1513398
Removing out of 4.1.9 as fix content for 4.2 has been enlarged significantly. Once we complete the task for 4.2, we will reconsider the backport again
Still not working properly. 1. Vms: comment != foo doesn't return VMs with empty comment 2. Vms: comment = "" got stuck in loading result and engine log contains 2018-02-23 11:07:37,661+01 INFO [org.ovirt.engine.core.bll.SearchQuery] (default task-5) [dd03dd0d-afe5-4ab9-b840-8351326f317b] ResourceManager::searchBusinessObjects - erroneous search text - ''Vms: comment='''' 2018-02-23 11:08:02,339+01 ERROR [org.ovirt.engine.core.bll.SearchQuery] (default task-9) [746605b8-d118-4a5b-bdb3-69dd76d10b06] Query 'SearchQuery' failed: StatementCallback; SQL [SELECT * FROM ((SELECT distinct vms.* FROM vms WHERE vms.free_text_comment = '' IS NOT FALSE ) ORDER BY vm_name ASC ) as T1 OFFSET (1 -1) LIMIT 100]; ERROR: invalid input syntax for type boolean: "" Position: 82; nested exception is org.postgresql.util.PSQLException: ERROR: invalid input syntax for type boolean: "" 3. Vms: comment != "" works fine The same is with Hosts, Storages search. tested in ovirt-engine-4.1.10.1-0.1.el7.noarch
Eli, are you looking into this?
(In reply to Yaniv Kaul from comment #11) > Eli, are you looking into this?, Yes, strange was verified on the 4.1 branch ....
(In reply to Lucie Leistnerova from comment #10) > Still not working properly. please attache the result of the following query from your database : SELECT * from vm_static where free_text_comment IS NULL;
Created attachment 1408375 [details] select output
I assume that the needinfo was for me. Select output attached.
(In reply to Lucie Leistnerova from comment #14) > Created attachment 1408375 [details] > select output Seems from the result that there are rows in vm_static with NULL altogether the upgrade script was supposed to change the default to empty string , I will try to reproduce Meanwhile to make sure that the upgrade script was installed on your database please provide also the following query : select * from schema_version order by id desc limit 3;
Well I reproduced the bug, however still don't know what is the cause The problem is that the script that was added in the patch changing columns default and existing values to empty string is installed according to the schema_version table, however , when you looking in the tables , for example vm_static, you see that data on that columns can still be null.... running the same upgrade script manually with psql , fixes the problem I will have to deep dive into it since I don't understand what is the cause for that behavior while master & 4.2 were verified on the same code ....
This is not going to make it to 4.1.10 - please re-target.
Fixing this issue is much more problematic then we thought, moving to 4.2.z but exact z-stream may be changed depending on fixing this on master
Still doesn't return items with empty values of Storage.description Storage.comment Vm.custom_emulated_machine Vm.custom_cpu_type Network.label Disk.description The engine was upgraded from 4.1 to 4.2.6 and I tested it also partialy on clean install. tested in ovirt-engine-4.2.6.3-1.el7.noarch
(In reply to Lucie Leistnerova from comment #21) > Still doesn't return items with empty values of > > Storage.description > Storage.comment > Vm.custom_emulated_machine > Vm.custom_cpu_type > Network.label > Disk.description > > The engine was upgraded from 4.1 to 4.2.6 and I tested it also partialy on > clean install. > > tested in ovirt-engine-4.2.6.3-1.el7.noarch We will address only : > Storage.description > Storage.comment > Disk.description The other fields will not be supported as it is to complicate to implement it, this should be documented
For all description and comment attributes the search works as expected. verified in ovirt-engine-4.2.7.1-0.1.el7ev.noarch Possible side effect of this change is reported in BZ 1633232
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, 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/RHBA-2018:3480