Created attachment 1139807 [details] Screenshot of the bug Description of problem: When using shared ISO Domain among 2+ Data Centers, the ISO domain itself does not appear under the storage tab for each data center. Please see attached screenshot. I am unable to thing of any reason for not showing it, is there one or this is indeed a bug? Version-Release number of selected component (if applicable): Red Hat Enterprise Virtualization Manager Version: 3.6.3.4-0.1.el6 How reproducible: Always Steps to Reproduce: 1. Create two Data Centers 2. Attach same ISO domain to Both 3. Using the Tree View, click on storage for a specific cluster Actual results: ISO Domain not shown in storage tab Expected results: ISO Domain shows in storage tab
Hello Tal, Thanks for looking at this. Do you need anything from me? I see the needinfo flag. Perhaps your message did not come through. Regards, Germano
Hi Germano, It was set by mistake, I will try to reproduce soon and will contact you if I will have any further questions, thanks!
oVirt 4.0 Alpha has been released, moving to oVirt 4.0 Beta target.
looks like the table storage_domains_for_search we use in the search backend is "array_to_string(array_agg(storage_pool.name), ','::text) AS pool_names" So the Data Center names for a shared ISO returns multiple names like "DC1,DC2" The search query uses this kind of search : WHERE storage_domains_for_search.storage_pool_name::text ILIKE '%SomeName%' and since the storage_pool_name is DC1,DC2 it never returns true.
The select phrase should be as follow: SELECT * FROM ((SELECT distinct storage_domains_for_search.* FROM storage_domains_for_search WHERE 'DataCenter' ILIKE ANY(string_to_array(storage_domains_for_search.storage_pool_name, ',')) ) ORDER BY storage_name ASC ) as T1 OFFSET (1 -1) LIMIT 100;
(In reply to Maor from comment #9) > The select phrase should be as follow: > > SELECT * FROM ((SELECT distinct storage_domains_for_search.* FROM > storage_domains_for_search WHERE 'DataCenter' ILIKE > ANY(string_to_array(storage_domains_for_search.storage_pool_name, ',')) ) > ORDER BY storage_name ASC ) as T1 OFFSET (1 -1) LIMIT 100; Eli, any chance the serachbackend can support that?
I have consulted with Martin P about that. Seems as an engine issue that should be addressed generally by core We will add an option to define additional metadata on columns that defined them as delimiter separated values and then we will apply the syntax that will make the query match with ANY of those values
After reproducing the problem and debugging, it seems not correct to solve it in the Search Engine domain: When selecting a storage under a data center dc1 for example from the tree, the tree constructs a search request with the following parameters : SearchParameters:{refresh='true', filtered='false', searchType='StorageDomain', searchPattern='Storage: datacenter = dc1 ', caseSensitive='false', from='0', max='100'} So, datacenter = dc1 is passed by the tree... It will be not correct to hack this value in the content of the Search Engine code The real origin of the problem is the definition of the storage_domains_for_search view which in the case described in BZ description field has the following record id | c377718f-afaf-4a98-8dc3-74ac1dfd4f93 storage | e5ff1244-36d4-4aa7-af6c-95f454da33e2 storage_name | ISO storage_description | storage_comment | storage_type | 1 storage_domain_type | 2 storage_domain_format_type | 0 last_time_used_as_master | 0 wipe_after_delete | f status | storage_pool_id | storage_pool_name | dc1,dc2 available_disk_size | 93 used_disk_size | 5 commited_disk_size | actual_images_size | storage_domain_shared_status | 2 recoverable | t contains_unregistered_entities | f warning_low_space_indicator | 10 critical_space_action_blocker | 5 external_status | 0 The problem is actually in the storage_pool_name field where we have the value 'dc1,dc2' IMO, the view should be changed to generate one record per DC , for example , for the data above : id | c377718f-afaf-4a98-8dc3-74ac1dfd4f93 storage | e5ff1244-36d4-4aa7-af6c-95f454da33e2 storage_name | ISO storage_description | storage_comment | storage_type | 1 storage_domain_type | 2 storage_domain_format_type | 0 last_time_used_as_master | 0 wipe_after_delete | f status | storage_pool_id | storage_pool_name | dc1 available_disk_size | 93 used_disk_size | 5 commited_disk_size | actual_images_size | storage_domain_shared_status | 2 recoverable | t contains_unregistered_entities | f warning_low_space_indicator | 10 critical_space_action_blocker | 5 external_status | 0 id | c377718f-afaf-4a98-8dc3-74ac1dfd4f93 storage | e5ff1244-36d4-4aa7-af6c-95f454da33e2 storage_name | ISO storage_description | storage_comment | storage_type | 1 storage_domain_type | 2 storage_domain_format_type | 0 last_time_used_as_master | 0 wipe_after_delete | f status | storage_pool_id | storage_pool_name | dc2 available_disk_size | 93 used_disk_size | 5 commited_disk_size | actual_images_size | storage_domain_shared_status | 2 recoverable | t contains_unregistered_entities | f warning_low_space_indicator | 10 critical_space_action_blocker | 5 external_status | 0 This will solve the issue and show the shared ISO domain in both DC storage tab. Allon, what do you think ?
We found another place in which this occur, when a disk is shared by 2 VMs I will try to find a solution in the context of the Search Engine
relevant test cases: RHEVM-17577, RHEVM-17578
Search with '=' operator works fine, shared storage/disk is shown and only once. So the link on Storages from left tree menu works. Search with '!=' operator fails on Storage: datacenter != Default and datacenter != dc2 - shared storage is shown in result, but should not be. The same is for shared disk and search Disks: vm_names != vm-test1 and vm_names != vm-test2 fails. tested in ovirt-engine-4.1.0.2-0.1.el7.noarch
Negated comparisons fix is tracked by BZ1252906 currently targeted to 4.2. Original reasoning of this bug doesn't mention negated comparisons, so moving back to ON_QA.
according to Comment 18 verified in ovirt-engine-4.1.0.2-0.1.el7.noarch