On 05/10/2016 11:20 AM, Aline Manera wrote:
On 05/10/2016 11:08 AM, Aline Manera wrote:
On 05/06/2016 05:43 PM, Daniel Henrique Barboza wrote:
Hi there,
I want to filter the interfaces listing in the UI when creating VEPA networks. Reason is that some network cards (you got it right - ConnectX-4 !!) does not have support for this kind of network yet.
Looking in the backend/UI code I want to discuss possible ways of filtering a collection listing. For the sake of this discussion let's assume that the 'module' parameter (the kernel module that loaded the interface) is already available at /plugins/kimchi/network/interfaces API:
(1) use query strings. For example, '/plugins/kimchi/vms?state=running' would list only the VMs that are running. Problem is that AFAIK I can't use a query string to say "I want all VMs but the ones running" or something like /plugins/kimchi/vms?state!=running. To do that I would need to first list all VMs then list the running VMs and do list_all - list_running . Or, in our case, list_all - list_connectx4.
I think it is possible to use "state!=running" while using query on API. Have you tested that?
If so, I'd say to go with this approach.
Or at least, I know we can use regex to determine the value of a field.
There was an issue with WoK mismatching regular expressions with negative lookahead (= match all but X ). I've fixed it in this patch: Fixing WoK match in search queries And now I'll go for implementation (1). If for some reason the criteria for listing VEPA interface become more complex then we can rethink this decision and perhaps go for (3), but (1) will suffice for now. Thanks!
(2) Implement it in JS. There are functions like 'loadInterfaces' which receives a filter option to get specific elements. It's easy to simply implement a 'loadVEPAInterfaces' and filter everything there. It wouldn't require to fire 2 GET requests and do a list operation to exclude the interfaces. We can simply work with the interfaces returned from the 'all' listing.
My issues with (1) and (2) is that I feel I am putting too much logic in UI code. Suppose that the criteria for VEPA networks changes and now it's not a simple matter of excluding the interfaces with module=mlx5_core. What then?
A backend solution would be, for example:
(3) Add a new parameter called 'vepa_capable' in network/interfaces API, then a simple call to /plugins/kimchi/network/interfaces?vepa_capable=true would return the information, with a single GET call, in a way that the UI would be oblivious of what's going on in the backend. We can change the backend logic anytime without messing with the UI calls
Of all these approaches I like (3) more, but not by far. This is why I want to hear options and perhaps other ideas aside from these 3.
Thanks,
Daniel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel