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

[Daniel Henrique Barboza]

On 05/10/2016 11:20 AM, Aline Manera wrote:
>
>
> 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.

There was an issue with WoK mismatching regular expressions with
negative lookahead (= match all but X ). I've fixed it in this patch:

  Fixing WoK match in search queries

And now I'll go for implementation (1). If for some reason the criteria for
listing VEPA interface become more complex then we can rethink this
decision and perhaps go for (3), but (1) will suffice for now.

Thanks!

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