Re: [Kimchi-devel] [RFC] How to filter certain interfaces for VEPA in the UI

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.

> >> (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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >> > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel >