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

[Daniel Henrique Barboza]

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.

(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