[NETVIRT-563] Elan interfaces are not always deleted after VM/port was deleted Created: 23/Mar/17  Updated: 19/Oct/17  Resolved: 06/Jul/17

Status: Resolved
Project: netvirt
Component/s: General
Affects Version/s: Boron
Fix Version/s: None

Type: Bug
Reporter: Mickael Strock-Vidal Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 8058

 Description   

Overview:
---------
In netvirt automated test we observed that some elan interfaces remains in the model after their related VMs/ports were deleted

For example:
------------
In the following jenkins job you can see that at the end of the serie of tests and after the VMs and ports are already deleted the elan interfaces still exist

https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-nodl-v2-upstream-transparent-boron/446/archives/log.html.gz#s1-s1-s3

Look under:
-----------
Test: Delete networks --> TEARDOWN --> KEYWORD : Get Model Dump --> For: @data models --> config/elan:elan-interfaces

As mentioned above, this issue was observed also during longevity test on a specific system and the none deletion of the elan interfaces caused system to be overloaded at some point

 Comments   
Comment by Koby Aizer [ 26/Mar/17 ]

Analysis:
ElanManager is listening on interface state changes, and eventually triggers InterfaceRemoveWorkerOnElanInterface, which eventually calls deleteElanInterfaceFromConfigDS.

However, deleteElanInterfaceFromConfigDS is not performing the delete when the ietf-interface still exists in the config DS.

When ietf-interface is eventually deleted (when the neutron config removal happens), nothing deletes the elan-interface – There is a comment inside handleNeutronPortDeleted that the ietf-interface deletion implicitly deletes the elan-interface, but it is wrong – This is only true when the interface-state still exits.

Generated at Wed Feb 07 20:21:53 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.