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

Aline Manera alinefm at linux.vnet.ibm.com
Tue May 10 14:08:45 UTC 2016



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.

> (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
>




More information about the Kimchi-devel mailing list