Bug 1178507 - [Network Custom Properties] Removal of an unmanaged network doesn't clear its properties
Summary: [Network Custom Properties] Removal of an unmanaged network doesn't clear its...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.5.0
Hardware: x86_64
OS: All
medium
high
Target Milestone: ovirt-3.6.0-rc3
: 3.6.0
Assignee: Martin Mucha
QA Contact: GenadiC
URL:
Whiteboard:
Depends On: 1136329 1246060
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-04 12:40 UTC by GenadiC
Modified: 2016-04-20 01:11 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-20 01:11:49 UTC
oVirt Team: Network
Target Upstream Version:
Embargoed:
ylavi: Triaged+


Attachments (Terms of Use)

Description GenadiC 2015-01-04 12:40:11 UTC
Description of problem:
Running automation test that creates Network, add Network Custom properties to this network and removes the network - leaves the DB filled with Network Custom properties on the interface.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Automation test that creates Network and attach it to Host
2. Configure bridge_opts of Network Custom properties feature
3. Remove Network from Setup (DC/Cluster and then Host)

Actual results:
After removal DB is still populated with ethtool_opts on interface (VDS interfaces table)

Expected results:
DB should be empty the moment the network was deleted from setup

Additional info:
Happened after running test case 13 from Network Custom properties job

Comment 1 Lior Vernia 2015-01-04 15:24:35 UTC
And a related but different bug - it's possible to supply network custom properties to a host interface via the Setup Networks API even if no network is attached to it (according to what I saw on your setup... I vaguely remember writing code to block this, but anyway...).

Comment 2 Yevgeny Zaspitsky 2015-07-27 13:09:38 UTC
Once 1136329 will be implemented custom properties will be stored in network attachments and the bug will be solved by cascading network delete.

Other thoughts on this matter:
There are 2 types of custom properties:
1. Some custom properties (e.g. bridging opts) are persistent on the VDSM side and some of them being reported back to the engine, though engine ignores that.
2. Any other non-persistent & not reported custom properties being stored in engine DB only.

IMHO, all persistent properties should be reported by VDSM to engine as they are host configuration and might be configured manually by a user (not through engine). Engine should track them for sync/un-sync decision.

Comment 3 Michael Burman 2015-10-26 11:53:01 UTC
Verified on - 3.6.0.2-0.1.el6 and vdsm-4.17.10-5.el7ev.noarch


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