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
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...).
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.
Verified on - 3.6.0.2-0.1.el6 and vdsm-4.17.10-5.el7ev.noarch