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/OPNFLWPLUG-1059 OpenFlowPlugin <p>The only remaining open loose end of <a href="https://jira.opendaylight.org/browse/OPNFLWPLUG-1046" title="Migrate OFP from XML to annotation based blueprint" class="issue-link" data-issue-key="OPNFLWPLUG-1046"><del>OPNFLWPLUG-1046</del></a> is this pesky little business:</p> <p><tt>org.opendaylight.genius.arputil.internal.ArpUtilImpl</tt> and <tt>org.opendaylight.genius.ipv6util.nd.Ipv6NsHelper</tt>, and possibly other places, require an OFP <tt>PacketProcessingService</tt> @Inject-ed.</p> <p>In our OSGi Karaf BP environment, this works via an <tt>&lt;odl:rpc-service&gt;</tt> in OSGI-INF/blueprint/arputil.xml and /OSGI-INF/blueprint/ipv6util.xml, which from what I gathered is provided by the <tt>org.opendaylight.openflowplugin.impl.services.sal.PacketProcessingServiceImpl</tt> that is registered as an <tt>&lt;odl:action-provider&gt;</tt> in OSGI-INF/blueprint/openflowplugin-impl.xml.</p> <p>What is an odl:action-provider? How does it obtain the RequestContextStack (of which there are several implementations), DeviceContext (apparently created by DeviceManagerImpl.createContext from a ConnectionContext) and ConvertorManager (looks easy) which it requires?</p> OPNFLWPLUG-1059

Migrate BP <odl:action-provider> for PacketProcessingService from XML to programmatic blueprint wiring

Improvement Medium Resolved Done Michael Vorburger Michael Vorburger Fri, 21 Dec 2018 14:52:01 +0000 Tue, 29 Jan 2019 14:04:18 +0000 Tue, 29 Jan 2019 14:03:32 +0000 Neon 0 2 <p><a href="https://jira.opendaylight.org/browse/CONTROLLER-1587" title="Fix blueprint assumptions around odl:rpc-service" class="issue-link" data-issue-key="CONTROLLER-1587"><del>CONTROLLER-1587</del></a>, <a href="https://jira.opendaylight.org/browse/OPNFLWPLUG-870" title="missing method to use barrier when installing dependant groups+flows or flows+packet_out" class="issue-link" data-issue-key="OPNFLWPLUG-870"><del>OPNFLWPLUG-870</del></a>, <a href="https://jira.opendaylight.org/browse/GENIUS-162" title="genius karaf log levels and messages should be checked" class="issue-link" data-issue-key="GENIUS-162"><del>GENIUS-162</del></a>, <a href="https://jira.opendaylight.org/browse/NETVIRT-988" title="IO Exception got while activating mip: Cannot run program &quot;cluster&quot;: error=2, No such file or directory" class="issue-link" data-issue-key="NETVIRT-988"><del>NETVIRT-988</del></a> mention/have logs related to PacketProcessingService ... Also looking at the source code of what the <tt>&lt;odl:action-provider&gt;</tt>  actually does could perhaps shed some light on this. But the easiest would be if someone actually had a good grasp on what magic is going on behind the scenes here and could jump in with an explanation here...</p> <p>Put in another way, to goal of this issue is just to get <a href="https://github.com/vorburger/opendaylight-simple/pull/76" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/vorburger/opendaylight-simple/pull/76</a> to pass...</p> <p>odl:action-provider basically wraps RpcProviderService.registerRpcImplementation just like odl:rpc-service. However if no implementation bean is provided, odl:action-provider registers a no-op implementation for each RPC - it seems this is for routed RPCs to register a placeholder for the actual instantiations that are registered in code per RPC context. This is done for PacketProcessingService in ./openflowplugin-impl/src/main/resources/OSGI-INF/blueprint/openflowplugin-impl.xml:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>&lt;odl:action-provider interface="org.opendaylight.yang.gen.v1.urn.opendaylight.packet.service.rev130709.PacketProcessingService"/&gt; </pre> </div></div> <p>I think to satisfy the odl:rpc-service BP dependency in consumers which waits for an underlying implementation to be available - which makes sense for "global" RPCs but not really for routed RPCs so hence the placeholder. Before odl:action-provider, odl:rpc-service happened to work b/c the placeholders were (incorrectly) provided by the sal-remoterpc-connector implementation. </p> <p>So for PacketProcessingService, no equivalent of odl:action-provider should be needed in ODL simple.</p> <p>&gt; no equivalent of odl:action-provider should be needed in ODL simple</p> <p>but e.g. (in genius) <tt>ArpUtilImpl</tt> and <tt>Ipv6NsHelper</tt> do require an OFP <tt>PacketProcessingService</tt> @Inject-ed, so what do we bind it to?</p> <p>&gt; the actual instantiations that are registered in code per RPC context</p> <p>perhaps we have a bigger issue with routed RPC in a standalone environment... the Guice (or other DI) framework probably needs to made to support those...</p> <p>&gt; perhaps we have a bigger issue with routed RPC in a standalone environment... the Guice (or other DI) framework probably needs to made to support those...</p> <p>right.. I think the binding of RPC consumers is currently compeltely wrong - we need to go through the... which one, RpcProviderRegistry or RpcProviderService?!</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=tpantelis" class="user-hover" rel="tpantelis">tpantelis</a> and I spoke for 1/2h by voice about this today and clarified what needs to be happen here next:</p> <p>The Guice *Module currently binds PacketProcessingService to PacketProcessingServiceImpl directly, and that was wrong &amp; NOK for a routed RPC - my bad, sorry.</p> <p>Instead, we need to use the <a href="https://github.com/opendaylight/mdsal/blob/master/binding/mdsal-binding-api/src/main/java/org/opendaylight/mdsal/binding/api/RpcConsumerRegistry.java" class="external-link" target="_blank" rel="nofollow noopener">mdsal.RpcConsumerRegistry</a>'s <tt>getRpcService()</tt>. (FTR: There is also the now <tt>@Deprecated</tt> <a href="https://github.com/opendaylight/controller/blob/master/opendaylight/md-sal/sal-binding-api/src/main/java/org/opendaylight/controller/sal/binding/api/RpcConsumerRegistry.java" class="external-link" target="_blank" rel="nofollow noopener">controller.RpcConsumerRegistry</a> but Tom says that it should be OK to only use <em>mdsal</em> one to look up the RPC - even if <em>openflowplugin</em> still uses the <em>controller</em> one to register the RPC - because behind the scenes they are, or should be, aligned.)</p> <p>&gt; So for PacketProcessingService, no equivalent of odl:action-provider should be needed in ODL simple.</p> <p>We also discussed this and weren't 100% sure.. so <a href="https://github.com/opendaylight/openflowplugin/search?q=RpcProviderRegistry&amp;unscoped_q=RpcProviderRegistry" class="external-link" target="_blank" rel="nofollow noopener">we can see that OFP</a> uses <a href="https://github.com/opendaylight/controller/blob/master/opendaylight/md-sal/sal-binding-api/src/main/java/org/opendaylight/controller/sal/binding/api/RpcProviderRegistry.java" class="external-link" target="_blank" rel="nofollow noopener">controller.RpcProviderRegistry</a> (and not, yet, the <a href="https://github.com/opendaylight/controller/blob/master/opendaylight/md-sal/sal-binding-api/src/main/java/org/opendaylight/controller/sal/binding/api/RpcProviderRegistry.java" class="external-link" target="_blank" rel="nofollow noopener">mdsal.RpcProviderService</a>) to register routed RPC implementations. We are unsure if this is sufficient; but if it's not, it actually seems trivial <a href="https://github.com/opendaylight/controller/blob/master/opendaylight/blueprint/src/main/java/org/opendaylight/controller/blueprint/ext/ActionProviderBean.java" class="external-link" target="_blank" rel="nofollow noopener">to do the equivalent of</a> &lt;odl:action-provider&gt; in a Guice Module.</p> <p>&gt; The Guice *Module currently binds PacketProcessingService to PacketProcessingServiceImpl directly, and that was wrong &amp; NOK for a routed &gt; RPC - my bad, sorry.</p> <p>It's NOK for global RPCs either. All RPC providers and consumers must go thru the *Registry interfaces. The consumer actually receives an internal proxy implementation that does various things including handling distributed RPC invocations across the cluster.</p> <p>My gut feeling is that the equivalent of &lt;odl:action-provider&gt; is not needed. IIRC, this was needed due to the BP extension waiting for an underlying DOM implementation to become available to satisfy the dependency (see my comment above on 12/Dec/18). </p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=tpantelis" class="user-hover" rel="tpantelis">tpantelis</a> I think <a href="https://github.com/vorburger/opendaylight-simple/commit/b9abb1de16eecd2467e9c8ca1bde527ccf8ca96b" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/vorburger/opendaylight-simple/commit/b9abb1de16eecd2467e9c8ca1bde527ccf8ca96b</a> is probably about right? <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=skitt" class="user-hover" rel="skitt">skitt</a> FYI, if interested.</p> <p>&gt; It's NOK for global RPCs either. All RPC providers and consumers must go thru the *Registry interfaces. The consumer actually receives an internal proxy implementation that does various things including handling distributed RPC invocations across the cluster.</p> <p>But have we actually implemented / are we really using distributed RPCs? Can you point to an example in an application?</p> <p>&gt; My gut feeling is that the equivalent of &lt;odl:action-provider&gt; is not needed.</p> <p>Yeah, it wasn't.</p> <p>I think it looks right. Does it work? If so then it's probably right <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>&gt; But have we actually implemented / are we really using distributed RPCs? Can you point to an example in an application?</p> <p>yes - opendaylight/md-sal/sal-remoterpc-connector in controller. Apps don't specifically use them - it's done transparently under the hood. Eg, OFP registers routed RPCs on the node that gets the entity ownership for the device - these RPCs are advertised across the cluster and can be invoked from any node. The app is unaware of this happening under the hood.</p> <p>for non-routed RPCs, how does it decide when to route an RPC to another node? (Asking because apart from this particular routed one in openflowplugin where we have to go through the mechanism,I'm reluctant to just let all and any other RPC calls go through a machine that is not needed in a simple package... my feeling is that it's overused; think something like genius lockmanager or idmanager - having those as RPC is non-sense, IMHO.)</p> <p>Routed and global RPCs work the same way. If there is a local implementation registered, it uses that otherwise it looks for a registration advertised from a remote node. If found, it proxies the RPC invocation across the wire (using akka) to the remote node. It's all part of ODL clustering.</p> <p>Anyway that's really orthogonal here. The bottom line is that you have to go thru the mdsal RPC registries to provide or consume RPC services for various reasons, otherwise it won't work properly. You can't just inject an RPC service implementation instance directly as you had originally done.</p> Blocks COE-51 OPNFLWPLUG-1046 Development Rank 0|i03lov: