[CONTROLLER-575] Change Node_Type and Node_ID in adaptors to match AD-SAL Created: 24/Jun/14  Updated: 19/Oct/17  Due: 01/Jul/14  Resolved: 05/May/15

Status: Resolved
Project: controller
Component/s: adsal
Affects Version/s: Helium
Fix Version/s: None

Type: Bug
Reporter: Ed Warnicke Assignee: Ed Warnicke
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS
Platform: PC

Attachments: Text File flow-install-trace.txt    
Issue Links:
Blocks
blocks OPNFLWPLUG-110 Milestone: AD-SAL Compatibility adapt... Resolved
is blocked by OPNFLWPLUG-121 Reserve ports should be logical ports Resolved
External issue ID: 1234

 Description   

Right now, the adaptors represent nodetype as MD_SAL and NodeId as openflow:<dpid> (basic passthrough) to the AD-SAL. In order to make the switch over, the adaptors need to start using the same NodeType and NodeID as are used in the AD-SAL case (which I think is NodeType OF and NodeID as the DPID in Mac address format (see picture here:
https://wiki.opendaylight.org/view/OpenDaylight_Controller:Installation#Using_the_Simple_Forwarding_Application )

We need to match this when represented from the adaptors to the AD-SAL.

 Comments   
Comment by Michal Rehak [ 25/Jun/14 ]

https://git.opendaylight.org/gerrit/#/c/8354/

Comment by Michal Rehak [ 26/Jun/14 ]

By OF-1.3 port number is of type uint32 (OF-1.0 uses uint16). Flows containing reserved ports are causing conversion exceptions. This can be fixed by using logical port instead of number of reserved port. Nevertheless OF-1.3 ports with value between max uint16 and reserved ports will cause expected exception as AD-SAL can not currently handle such port values.

Comment by Michal Rehak [ 27/Jun/14 ]

improved nodeConnection names and descriptions to match original AD-SAL stuff
https://git.opendaylight.org/gerrit/#/c/8423/

Comment by Shigeru Yasuda [ 30/Jun/14 ]

I guess this change may disable AD-SAL openflow plugin unexpectedly.

After this change, VTN Manager is unable to install flow entry occasionally.
An IllegalStateException was logged when VTN Manager tried to install a flow
entry.

java.lang.IllegalStateException: No default provider is available

I found the following trace logs.

2014-06-30 19:47:07.863 GMT+09:00 [fileinstall-./plugins] TRACE \
o.o.c.s.i.i.FlowProgrammerService - Got a service set request \
org.opendaylight.controller.protocol_plugin.openflow.internal.FlowProgrammerService@16ddd90
2014-06-30 19:47:07.864 GMT+09:00 [fileinstall-./plugins] TRACE \
o.o.c.s.i.i.FlowProgrammerService - Prop key:(service.id) value:(171)
2014-06-30 19:47:07.865 GMT+09:00 [fileinstall-./plugins] TRACE \
o.o.c.s.i.i.FlowProgrammerService - Prop key:(protocolPluginType) value:(OF)

[... snipped ...]

2014-06-30 19:47:07.865 GMT+09:00 [fileinstall-./plugins] TRACE \
o.o.c.s.i.i.FlowProgrammerService - Got a service set request \
org.opendaylight.controller.sal.compatibility.FlowProgrammerAdapter@354f95
2014-06-30 19:47:07.865 GMT+09:00 [fileinstall-./plugins] TRACE \
o.o.c.s.i.i.FlowProgrammerService - Prop key:(service.id) value:(117)
2014-06-30 19:47:07.865 GMT+09:00 [fileinstall-./plugins] TRACE \
o.o.c.s.i.i.FlowProgrammerService - Prop key:(objectClass) value:\
([org.opendaylight.controller.sal.flowprogrammer.IPluginInFlowProgrammerService])
2014-06-30 19:47:07.865 GMT+09:00 [fileinstall-./plugins] TRACE \
o.o.c.s.i.i.FlowProgrammerService - Prop key:(protocolPluginType) value:(OF)

MD-SAL service overrides IPluginInFlowProgrammerService for "OF" type when
it is loaded after AD-SAL openflow plugin. I guess the same problem can happen
to DataPacketService and ReadService too.

Comment by Shigeru Yasuda [ 30/Jun/14 ]

If IPluginInFlowProgrammerService is overridden by MD-SAL, this trace is logged
every time VTN Manager installs a flow entry.

Comment by Shigeru Yasuda [ 30/Jun/14 ]

Attachment flow-install-trace.txt has been added with description: Stack trace caused by SalFlowService

Comment by Michal Rehak [ 02/Jul/14 ]

Hi,
the reason for using the same names for registration is in FlowProgrammerService. All flow manipulating methods look up appropriate flow programmer using the type of input node as search criteria.

If we want to have a seamless replacement for ad-sal flow programmer implementation, then the naming has to be this way. Now we can either add some hack here in order to distinguish between those 2 implementations or we can force to have only one implementation available for osgi at the same time.

Comment by Shigeru Yasuda [ 02/Jul/14 ]

Hi Michal,

This issue is harmless to official distributions built by integration.git
project because sal-compatibility bundle is not loaded unless "-of13" switch
is specified to run.sh. So I think we do not need to give high priority to task
for solving this issue.

I guess we can fix this issue by setting a priority value into plugin service
property. I will try to write a patch later.

Comment by Shigeru Yasuda [ 09/Jul/14 ]

I wrote a patch that gives higher priority to legacy OF plugin than
sal-compatibility.

https://git.opendaylight.org/gerrit/8860

Comment by Carol Sanders [ 05/May/15 ]

This bug is part of the project to Move all ADSAL associated component bugs to ADSAL.

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