4:08 p.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel