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
the OS type is an enum. We would need to add wildcard functionality to enums I guess. Martine?
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?
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
(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?
(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
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.
BZ<2>Jira Resync