Bug 1303151 - [RFE] Wildcard for OS should work for all available matches
[RFE] Wildcard for OS should work for all available matches
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs (Show other bugs)
3.5.7
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eli Mesika
Gil Klein
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-29 12:00 EST by Ulhas Surse
Modified: 2018-06-18 09:09 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-06-18 09:09:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ulhas Surse 2016-01-29 12:00:38 EST
3. What is the nature and description of the request?
   When trying to filter on os in RHEV-M. You're not able to use wildcards. For example if you want to filter out all Windows, you can't use windows*. Instead you need to specify all Windows versions, one by one.

4. Why does the customer need this? (List the business requirements here)
   To be able to easily check which servers has the latest RHEV-Tools.

5. How would the customer like to achieve this? (List the functional requirements here)
   For example, I would like to use this filter: vms: os = windows* and apps != "RHEV-Tools 3.5.14". Then I can easily go through the list of Windows servers (regardless of version) that needs to be updated, or have the RHEV Tools installed.

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
   Yes

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
   No

8. Does the customer have any specific time-line dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
   No

9. Is the sales team involved in this request and do they have any additional input?
   No

10. List any affected packages or components.
    rhevm-webadmin-portal-3.5.7-0.1.el6ev.noarch

11. Would the customer be able to assist in testing this functionality if implemented?
    Yes
Comment 6 Michal Skrivanek 2017-05-31 04:17:39 EDT
the OS type is an enum. We would need to add wildcard functionality to enums I guess. Martine?
Comment 8 Martin Perina 2017-06-19 09:23:14 EDT
This change is very hard to implement within our current SearchBackend implementation and could cause a lot of side effects. So I'm suggesting to close it as WONTFIX. Moran?
Comment 9 Martin Tessun 2017-06-23 04:14:41 EDT
Hi Martin,

(In reply to Martin Perina from comment #8)
> This change is very hard to implement within our current SearchBackend
> implementation and could cause a lot of side effects. So I'm suggesting to
> close it as WONTFIX. Moran?

I tend to agree, just adding some more justification around this:
The OS field is an enum field as of now. So chosing e.g. "Win*" as a value would result in a query that needs to expand to all possible enum fields first and then add these as a "<Value> IN <List>" statement.
This gets even more complex as there are some fields requiring exact values, like the "date" field.

As the change would be considered very intrusive and there is only limited benefit, this will not be implemented the requested way.

Maybe there are other ways (e.g. adding additional fields used by Wildcard searches that are not enum fields, but having the same content, etc.) to implement a consistent "search" experience without being too intrusive.

Leaving the final voice to Moran, though
Comment 10 Moran Goldboim 2017-07-02 10:48:38 EDT
(In reply to Martin Tessun from comment #9)
> Hi Martin,
> 
> (In reply to Martin Perina from comment #8)
> > This change is very hard to implement within our current SearchBackend
> > implementation and could cause a lot of side effects. So I'm suggesting to
> > close it as WONTFIX. Moran?
> 
> I tend to agree, just adding some more justification around this:
> The OS field is an enum field as of now. So chosing e.g. "Win*" as a value
> would result in a query that needs to expand to all possible enum fields
> first and then add these as a "<Value> IN <List>" statement.
> This gets even more complex as there are some fields requiring exact values,
> like the "date" field.
> 
> As the change would be considered very intrusive and there is only limited
> benefit, this will not be implemented the requested way.
> 
> Maybe there are other ways (e.g. adding additional fields used by Wildcard
> searches that are not enum fields, but having the same content, etc.) to
> implement a consistent "search" experience without being too intrusive.
> 
> Leaving the final voice to Moran, though

Ulhas, can we check if working around this problems using Tags - tagging all the windows VMs under one tag can work here?
Comment 11 Eli Mesika 2017-07-03 04:18:39 EDT
(In reply to Moran Goldboim from comment #10)

> Ulhas, can we check if working around this problems using Tags - tagging all
> the windows VMs under one tag can work here?

Sure
Comment 13 Martin Tessun 2018-06-18 09:09:02 EDT
Thank you for submitting this request for inclusion in Red Hat Virtualization. We've carefully evaluated the request, but are unable to include it in a future release. To request that Red Hat re-consider this request, please re-open the bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you.

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