[OPNFLWPLUG-854] Change switch mastership before starting services Created: 14/Feb/17  Updated: 27/Sep/21  Resolved: 11/Jun/18

Status: Resolved
Project: OpenFlowPlugin
Component/s: clustering
Affects Version/s: None
Fix Version/s: Oxygen

Type: Improvement
Reporter: Jon Castro Assignee: Anil Vishnoi
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All



 Description   

DeviceContextImpl.java class is first starting services before changing mastership on the switch. This could lead to potential race conditions which controllers start sending changes before being master.

I suggest that DeviceContextImpl.java should first ensure it holds the mastership to the switch and if it works start the services.

So, the method

public boolean onContextInstantiateService(final ConnectionContext connectionContext) {

Should call following line after checking connection is not dead.

Futures.addCallback(sendRoleChangeToDevice(OfpRole.BECOMEMASTER), new RpcResultFutureCallback());

For example,

@Override
public boolean onContextInstantiateService(final ConnectionContext connectionContext) {

if (getPrimaryConnectionContext().getConnectionState().equals(ConnectionContext.CONNECTION_STATE.RIP)) {
LOG.warn("Connection on device {} was interrupted, will stop starting master services.", deviceInfo.getLOGValue());
return false;
}

Futures.addCallback(sendRoleChangeToDevice(OfpRole.BECOMEMASTER), new RpcResultFutureCallback());



 Comments   
Comment by Jon Castro [ 14/Feb/17 ]

Currently, DeviceContextImpl starts first services which implies many openflow messages being sent to the switch like get ports configuration etc.

Some switches might not behave properly in slave mode.

Chaning the order as suggested by this bug will ensure that the controller owns mastership before sending any type of message.

Comment by Jozef Bacigal [ 12/May/17 ]

Actually is there some issue or should this be as an improvement.

But you should check actual code on carbon/nitrogen branch. Many has been changed.

Comment by Anil Vishnoi [ 11/Jun/18 ]

It's already fixed in nitrogen/oxygen/Fluorine

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