https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/CONTROLLER-575 controller <p>Right now, the adaptors represent nodetype as MD_SAL and NodeId as openflow:&lt;dpid&gt; (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: <br/> <a href="https://wiki.opendaylight.org/view/OpenDaylight_Controller:Installation#Using_the_Simple_Forwarding_Application" class="external-link" target="_blank" rel="nofollow noopener">https://wiki.opendaylight.org/view/OpenDaylight_Controller:Installation#Using_the_Simple_Forwarding_Application</a> )</p> <p>We need to match this when represented from the adaptors to the AD-SAL.</p> <p>Operating System: Mac OS<br/> Platform: PC</p> CONTROLLER-575

Change Node_Type and Node_ID in adaptors to match AD-SAL

Bug Resolved Done Ed Warnicke Ed Warnicke Tue, 24 Jun 2014 00:35:38 +0000 Thu, 19 Oct 2017 15:31:08 +0000 Tue, 5 May 2015 15:17:30 +0000 Helium adsal Tue, 1 Jul 2014 00:00:00 +0000 0 5 <p><a href="https://git.opendaylight.org/gerrit/#/c/8354/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/8354/</a></p> <p>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.</p> <p>improved nodeConnection names and descriptions to match original AD-SAL stuff<br/> <a href="https://git.opendaylight.org/gerrit/#/c/8423/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/8423/</a></p> <p>I guess this change may disable AD-SAL openflow plugin unexpectedly.</p> <p>After this change, VTN Manager is unable to install flow entry occasionally.<br/> An IllegalStateException was logged when VTN Manager tried to install a flow<br/> entry.</p> <p> java.lang.IllegalStateException: No default provider is available</p> <p>I found the following trace logs.</p> <p> 2014-06-30 19:47:07.863 GMT+09:00 <span class="error">&#91;fileinstall-./plugins&#93;</span> TRACE \<br/> o.o.c.s.i.i.FlowProgrammerService - Got a service set request \<br/> org.opendaylight.controller.protocol_plugin.openflow.internal.FlowProgrammerService@16ddd90<br/> 2014-06-30 19:47:07.864 GMT+09:00 <span class="error">&#91;fileinstall-./plugins&#93;</span> TRACE \<br/> o.o.c.s.i.i.FlowProgrammerService - Prop key:(service.id) value:(171)<br/> 2014-06-30 19:47:07.865 GMT+09:00 <span class="error">&#91;fileinstall-./plugins&#93;</span> TRACE \<br/> o.o.c.s.i.i.FlowProgrammerService - Prop key:(protocolPluginType) value:(OF)</p> <p> <span class="error">&#91;... snipped ...&#93;</span></p> <p> 2014-06-30 19:47:07.865 GMT+09:00 <span class="error">&#91;fileinstall-./plugins&#93;</span> TRACE \<br/> o.o.c.s.i.i.FlowProgrammerService - Got a service set request \<br/> org.opendaylight.controller.sal.compatibility.FlowProgrammerAdapter@354f95<br/> 2014-06-30 19:47:07.865 GMT+09:00 <span class="error">&#91;fileinstall-./plugins&#93;</span> TRACE \<br/> o.o.c.s.i.i.FlowProgrammerService - Prop key:(service.id) value:(117)<br/> 2014-06-30 19:47:07.865 GMT+09:00 <span class="error">&#91;fileinstall-./plugins&#93;</span> TRACE \<br/> o.o.c.s.i.i.FlowProgrammerService - Prop key:(objectClass) value:\<br/> (<span class="error">&#91;org.opendaylight.controller.sal.flowprogrammer.IPluginInFlowProgrammerService&#93;</span>)<br/> 2014-06-30 19:47:07.865 GMT+09:00 <span class="error">&#91;fileinstall-./plugins&#93;</span> TRACE \<br/> o.o.c.s.i.i.FlowProgrammerService - Prop key:(protocolPluginType) value:(OF)</p> <p>MD-SAL service overrides IPluginInFlowProgrammerService for "OF" type when<br/> it is loaded after AD-SAL openflow plugin. I guess the same problem can happen<br/> to DataPacketService and ReadService too.</p> <p>If IPluginInFlowProgrammerService is overridden by MD-SAL, this trace is logged<br/> every time VTN Manager installs a flow entry.</p> <p>Attachment flow-install-trace.txt has been added with description: Stack trace caused by SalFlowService</p> <p>Hi,<br/> 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.</p> <p>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.</p> <p>Hi Michal,</p> <p>This issue is harmless to official distributions built by integration.git<br/> project because sal-compatibility bundle is not loaded unless "-of13" switch<br/> is specified to run.sh. So I think we do not need to give high priority to task<br/> for solving this issue.</p> <p>I guess we can fix this issue by setting a priority value into plugin service<br/> property. I will try to write a patch later.</p> <p>I wrote a patch that gives higher priority to legacy OF plugin than<br/> sal-compatibility.</p> <p> <a href="https://git.opendaylight.org/gerrit/8860" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/8860</a></p> <p>This bug is part of the project to Move all ADSAL associated component bugs to ADSAL.</p> Blocks OPNFLWPLUG-110 OPNFLWPLUG-121 Development External issue ID 1234 External issue URL Rank 0|i02l8v: