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

[Aline Manera]

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