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