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-1587 controller <p>The odl:rpc-service extension makes assumptions about RPC lifecycle which are not strictly true when the definition is translated to DOMRpcIdentifier, most notably about when an RPC implementation is registered.</p> <p>Current codebase happens to work due to how sal-remoterpc-connector integrates with DOMRpcRouter, but that integration needs to be redone to fix BUG-3128. That in turn breaks assumptions in blueprint.</p> <p>Refine the odl:rpc-service contract to cover registration semantics with respect to routed RPCs and implement it in a way, which will not break in absence of sal-remoterpc-connector.</p> <p>Operating System: All<br/> Platform: All</p> CONTROLLER-1587

Fix blueprint assumptions around odl:rpc-service

Bug Resolved Done Robert Varga Robert Varga Fri, 20 Jan 2017 10:26:34 +0000 Tue, 25 Jul 2023 08:24:20 +0000 Thu, 9 Feb 2017 10:30:10 +0000 blueprint 0 1 <p>Additional analysis shows that the problem is interaction between blueprint's (and by extension end-user's) expectation versus how RPC routing works.</p> <p>Current BP odl:rpc-service and odl:rpc-implementation can only work as envisioned for binding FooService completely composed of global RPCs. It acts as a dependency activation gate before the component activates.</p> <p>Routed RPCs ('actions' to use RFC7950 term) work in a rather different way, as they come and go as their contexts change. In this case BP wiring really wants to express a dependency on 'someone has promised to instantiate actions'.</p> <p>That contract is currently 'provided' by sal-remoterpc-connector by blanked-subscribing as an implementation for all actions. This has the side-effect of rendering BP dependency wiring in this case not working, for example for OFP's lldp-speaker.xml &#8211; it depends on PacketProcessingService, which is supposed to be exported from openflowplugin's blueprint (i.e. OFP instance registers actions for each connect OF switch). But lldp-speaker activation will not be blocked waiting for openflowplugin, but rather it will activate immediately due to sal-remoterpc-connector pretending to provide that promise. </p> <p>Another layer of features is to have beans dynamically start when a specific action (on a context) is registered, but making that work means we have to actually react to actions and RPCs disappearing &#8211; this is out of scope of this issue, but needs to be considered in the solution domain here.</p> <p>To solve this issue and BUG-3128 without breaking the world, we will need to provide a partial fix for this issue, then fix sal-remoterpc-connector (and DOMRpcBroker) and then finalize the fix for this issue.</p> <p>The fix is to provide a clear split between actions and rpcs, in a way which is forward-compatible with YANG 1.1 and Java Binding V2 (where each action is its own entity).</p> <p>This will be done by defining a odl:action-service and odl:action-provider, which mirror the semantics of odl:rpc-</p> {service,implementation} <p>.</p> <p>An odl:action-provider designates a bean, which holds the promise to instantiate action instances. As soon as that bean is instantiated, the promise is fulfilled and the promise is populated into DOMRpcRegistry.</p> <p>An odl:action-service declares a dependency to have at least one odl:action-provider active.</p> <p>The terms odl:action-instance and odl:action-implementation are reserved for future use. odl:action-implementation will provide an implementation of an action on a particular context (much like odl:routed-rpc-implementation). odl:action-instance will be used to reference to action-implementation. This will be added to XSD, but will be left unimplemented until such time as true dynamic services are needed.</p> <p>The first part of the fix is to provide these concepts and add a basic compatible implementation, i.e. odl:action-service will be always considered to be fulfilled if a model for it exists. The code will also detect and warn about ambiguous use of odl:rpc-service when the specified interface also contains an action (routed RPC).</p> <p>DOMRpcService contract clarification: <a href="https://git.opendaylight.org/gerrit/51034" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/51034</a></p> <p>New action-provider/action-service contracts: <a href="https://git.opendaylight.org/gerrit/50784" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/50784</a><br/> OFP fix (requiring the above): <a href="https://git.opendaylight.org/gerrit/51115" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/51115</a><br/> Final activation: <a href="https://git.opendaylight.org/gerrit/51114" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/51114</a></p> <p>boron: <a href="https://git.opendaylight.org/gerrit/51204" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/51204</a></p> <p>rpc error</p> <p>Attachment rpcerror.txt has been added with description: rpc error</p> <p>log</p> <p>Attachment karaf_log_error.txt has been added with description: log</p> <p>This does not quite work in cluster singleton service</p> <p>our blueprint configuration<br/> <a href="https://github.com/opendaylight/groupbasedpolicy/blob/master/renderers/vpp/src/main/resources/org/opendaylight/blueprint/vpp-renderer.xml" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/opendaylight/groupbasedpolicy/blob/master/renderers/vpp/src/main/resources/org/opendaylight/blueprint/vpp-renderer.xml</a></p> <p> &lt;bean id="vppRenderer" class="org.opendaylight.controller.config.yang.config.vpp_provider.impl.GbpVppProviderInstance"<br/> init-method="initialize" destroy-method="close"&gt;<br/> &lt;argument ref="dataBroker"/&gt;<br/> &lt;argument ref="broker"/&gt;<br/> &lt;argument ref="clusterSingletonService" /&gt;<br/> &lt;/bean&gt;</p> <p> &lt;odl:rpc-implementation ref="vppRenderer"/&gt;</p> <p>Errors are returned, when sending RPCs to follower node (not leader).<br/> Please see rpc_error and log in the attachment.</p> <p>NPE is caught here on line 104</p> <p><a href="https://github.com/opendaylight/groupbasedpolicy/blob/master/renderers/vpp/src/main/java/org/opendaylight/controller/config/yang/config/vpp_provider/impl/GbpVppProviderInstance.java" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/opendaylight/groupbasedpolicy/blob/master/renderers/vpp/src/main/java/org/opendaylight/controller/config/yang/config/vpp_provider/impl/GbpVppProviderInstance.java</a></p> <p> @Override<br/> public Future&lt;RpcResult&lt;Void&gt;&gt; createVirtualBridgeDomainOnNodes(CreateVirtualBridgeDomainOnNodesInput input) </p> { return renderer.getVppRpcServiceImpl().createVirtualBridgeDomain(input); } <p>However, RPCs are processed correctly when sent to the leader node.</p> <p>Of course it does not. The reason for that is that the GbpVppProviderInstance is not fully initialized by the time it gets registered as a provider &#8211; i.e. instantiateServiceInstance() has not been called.</p> <p>This effectively means you cannot use odl:rpc-implementation to inject the bean as an implementation &#8211; you have to do it yourself from instantiateServiceInstance()... unless there is a blueprint way to have GbpVppProviderInstance bean created based on singleton service.</p> <p>So with the current setup you are registering an implementation on each node, even before it is fully initialized. Once singleton does its thing, one of the implementations will become operational &#8211; but there is a time window when you already have registered it, but it is not initialized.</p> <p>RPCs are always routed to the closest registered instance, in this case it will end up always being the local one &#8211; whether it is operational or not.</p> Blocks CONTROLLER-1292 Development External issue ID 7608 External issue URL Issue Type ODL SR Target Milestone Rank 0|i02rhr: