Bug 1411666 - [SR-IOV] - UI - Reflect 'No Filter' for passthrough vNIC profile that was created via rest api
Summary: [SR-IOV] - UI - Reflect 'No Filter' for passthrough vNIC profile that was cre...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network
Version: 4.1.0
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ovirt-4.1.2
: 4.1.2
Assignee: Martin Mucha
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-10 09:17 UTC by Michael Burman
Modified: 2017-05-23 08:18 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-23 08:18:41 UTC
oVirt Team: Network
rule-engine: ovirt-4.1+


Attachments (Terms of Use)
screenshots (50.70 KB, application/x-gzip)
2017-01-10 09:17 UTC, Michael Burman
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 71806 0 master MERGED core: missing validation 2017-03-02 09:53:00 UTC
oVirt gerrit 73613 0 ovirt-engine-4.1 MERGED core: missing validation 2017-04-19 11:07:26 UTC

Description Michael Burman 2017-01-10 09:17:45 UTC
Created attachment 1239016 [details]
screenshots

Description of problem:
[SR-IOV] - UI - Reflect 'No Filter' for passthrough vNIC profile that was created via rest api.

When creating/editing vNIC profile with a 'passthrough' property in the UI, it is immediately reflects as grayed out and 'No Filter' displayed.

But when creating/editing the same the vNIC profile with a 'passthrough' property via the rest api, the engine UI, display it as grayed out, but the 'vdsm-no-mac-spoofing' filter still visible, but it shouldn't.

Version-Release number of selected component (if applicable):
4.1.0-0.4.master.20170109222652.git53fd6cb.el7.centos

How reproducible:
100

Steps to Reproduce:
1. Create vNIC profile with 'passthrough' property via rest api

Actual results:
In the UI, the 'vdsm-no-mac-spoofing' filter still visible

Expected results:
If 'passthrough' checked we shouldn't see any network filter.

Comment 1 Dan Kenigsberg 2017-01-10 09:23:07 UTC
What happens when the VM is started? Does Engine request filter=vdsm-no-mac-spoofing ?

Comment 2 Michael Burman 2017-01-10 09:26:13 UTC
(In reply to Dan Kenigsberg from comment #1)
> What happens when the VM is started? Does Engine request
> filter=vdsm-no-mac-spoofing ?

No, it is just a small ui bug. When VM starts it has no filter

Comment 3 Martin Mucha 2017-02-07 12:38:04 UTC
I don't believe it's small ui bug, I believe it's bigger backend bug. But I cannot tell, because there's no REST request you used or explaining description how you achieved this. Please next time provide that for simplifying flow.

What I assume you did: you took existing response returned via GET method, and used that to create new vNIC profile; you just removed ID and changed name in that xml. That would mean, that there's specified network_filter having name vdsm-no-mac-spoofing. Which is invalid request, because only "no network filter" can be specified. Am I right?

If I am, then there's incomplete validation phase in:
UpdateVnicProfileCommand
and
AddVnicProfileCommand,
while UI is fine.

Can you confirm this?

Comment 4 Martin Mucha 2017-02-07 12:50:13 UTC
checking deeper, error (?) seems to be in REST layer.

If someone tries to add new vnic_profile using request, which lacks specified network_filter, default one is used, which currently happens to be vdsm-no-mac-spoofing.

So it seems (please correct me if I'm wrong), that you cannot create vnic_profile without network_filter via REST. You can do it only via UI.

If that's correct, I can easily fix that automatic use of default, but this will harm backward compatibility. Shall this be fixed?

To solve this specific bug, I can 'override' this logic and set no filter for each passthrough vnic_profile, but error mentioned above is probably worse.

Comment 5 Meni Yakove 2017-02-07 13:33:12 UTC
This creates new vnic_profile without network filter.

CREATE ovirt-engine/api/vnicprofiles
<vnic_profile>
    <name>test_vnic</name>
    <network href="/ovirt-engine/api/networks/030cdc7e-c153-4253-b843-10482e798e1e" id="030cdc7e-c153-4253-b843-10482e798e1e">
        <name>ovirtmgmt</name>
        <description>Default Management Network</description>
        <link href="/ovirt-engine/api/networks/030cdc7e-c153-4253-b843-10482e798e1e/vnicprofiles" rel="vnicprofiles"/>
        <link href="/ovirt-engine/api/networks/030cdc7e-c153-4253-b843-10482e798e1e/permissions" rel="permissions"/>
        <link href="/ovirt-engine/api/networks/030cdc7e-c153-4253-b843-10482e798e1e/networklabels" rel="networklabels"/>
        <mtu>0</mtu>
        <stp>false</stp>
        <usages>
            <usage>vm</usage>
        </usages>
        <data_center href="/ovirt-engine/api/datacenters/345f8890-24a6-4395-a767-6c78570e45ed" id="345f8890-24a6-4395-a767-6c78570e45ed"/>
    </network>
    <network_filter/>
</vnic_profile>

Comment 6 Martin Mucha 2017-02-07 17:08:54 UTC
thanks for info about rest. Then it's about missing validations on bll layer. Seems to working after change, waiting for review.

Comment 7 Michael Burman 2017-04-27 08:05:55 UTC
No longer depend on bz 1445759 as it has WA if sending network filter as null.

Verified on - 4.1.2-0.1.el7


Note You need to log in before you can comment on or make changes to this bug.