[NETVIRT-73] Group installation relies on timeouts. This is wrong. Created: 17/Aug/16  Updated: 29/May/18  Resolved: 31/Aug/16

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

Type: Bug
Reporter: Josh Hershberg Assignee: Periyasamy Palanisamy
Resolution: Won't Do 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: 6447

 Description   

In the file ElanInterfaceManager:

public void installEntriesForFirstInterfaceonDpn(ElanInstance elanInfo, InterfaceInfo interfaceInfo,
DpnInterfaces dpnInterfaces, boolean isFirstInterfaceInDpn, WriteTransaction tx) {
if (!isOperational(interfaceInfo))

{ return; }

// LocalBroadcast Group creation with elan-Interfaces
setupLocalBroadcastGroups(elanInfo, dpnInterfaces, interfaceInfo);
if (isFirstInterfaceInDpn) {
LOG.trace("waitTimeForSyncInstall is {}", WAIT_TIME_FOR_SYNC_INSTALL);
BigInteger dpId = interfaceInfo.getDpId();
// RemoteBroadcast Group creation
try

{ Thread.sleep(WAIT_TIME_FOR_SYNC_INSTALL); } catch (InterruptedException e1) {
LOG.warn("Error while waiting for local BC group for ELAN {} to install", elanInfo);
}
setupElanBroadcastGroups(elanInfo, dpnInterfaces, dpId);
try { Thread.sleep(WAIT_TIME_FOR_SYNC_INSTALL); }

catch (InterruptedException e1) {
LOG.warn("Error while waiting for local BC group for ELAN {} to install", elanInfo);
}
}
}

 Comments   
Comment by Periyasamy Palanisamy [ 31/Aug/16 ]

This can be solved by depending on group stat replies once group is written into inventory config DS. This approach was tried in lithium release, but it introduced latency in each group programming (from 3s to 12s) and also unnecessary periodic groups stats from ODL.
So group stat dependency is removed in beryllium code and added this time delay.
With this change, ELAN works fine even in highly scaled deployments (example: 400 ELAN and 8000 ports) without any race conditions.

If Lithium plugin's salgroupservice solves this issue, then we can go ahead and bypass FRM to program the groups at the cost of service modules taking care of group reconciliation. So it is not candidate for boron and we can take it up later (may be in Carbon).

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