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/NETCONF-669 netconf <p>NETCONF is currently abusing DOMMountPoint and especially DOMRpcService to funnel unparsed anyxml nodes through DOM interfaces.</p> <p>This relies on a historic leniency of DOMRpcResult of allowing other nodes than containers to carry the result.</p> <p>This is completely wrong, as NETCONF mount points which do not have a schema should not expose a DOMRpcService, but some completely different service, which does not play pretend it conforms to DOMRpcService specification.</p> <p>Most notable example is that while normal mount points can be interacted with via Binding components, as we can make sense of the payload. schemaless mounts cannot – yet they pretend their services can in fact be a source of normalized data.</p> NETCONF-669

Separate out schemaless mountpoints

New Feature Highest Resolved Done Robert Varga Robert Varga pt Thu, 23 Apr 2020 14:24:43 +0000 Thu, 29 Dec 2022 21:40:55 +0000 Thu, 29 Dec 2022 21:40:46 +0000 5.0.0 netconf 0 1 <p>RESTCONF participates in this game in that this API difference needs to be understood by RESTCONF, which gets the onus of dealing with XML-&gt;JSON translation without ever knowing the schema.</p> <p>This is manifested at RemoteDeviceHandler exposing DOMRpcService – here input and output are required to be ContainerNodes. There are two implementations plugged into this – NetconfDeviceRpc and SchemalessNetconfDeviceRpc.</p> <p>So now, we need a sal.connect.api.RemoteDeviceRpcs:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> sealed <span class="code-keyword">interface</span> RemoteDeviceRpcs { non-sealed <span class="code-keyword">interface</span> Normalized <span class="code-keyword">extends</span> RemoteDeviceRpcs, DOMRpcService { <span class="code-comment">// Nothing <span class="code-keyword">else</span> needed </span> } non-sealed <span class="code-keyword">interface</span> Raw <span class="code-keyword">extends</span> RemoteDeviceRpcs, DocumentRpcService { <span class="code-comment">// Nothing <span class="code-keyword">else</span> needed </span> } } </pre> </div></div> <p>plus, we need to define a new DOMService:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-keyword">import</span> org.w3c.Document; <span class="code-keyword">interface</span> DocumentRpcService <span class="code-keyword">extends</span> DOMService { ListenableFuture&lt;? <span class="code-keyword">extends</span> Document&gt; invokeRpc(@NonNull <span class="code-object">String</span> namespaceURI, @NonNull <span class="code-object">String</span> localName, @NonNull Document input); } </pre> </div></div> <p>The result may perhaps be not a Document, but a more structured thing – that is left to be determined based on integration experience.</p> <p> </p> <p>Also, <a href="https://git.opendaylight.org/gerrit/c/netconf/+/103168" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/c/netconf/+/103168</a> is already flushing the incompatibility, hence we will need a solution quite soon.</p> <p>A bit of prototyping shows that this may actually need to addressed starting with the interface exposed by SchemalessNetconfDevice – i.e. it probably should have its own RemoteDeviceHandler.</p> <p>(brain dump)<br/> Looking at this a bit more, we could start by making RemoteDeviceHandler disconnect from DOM concepts and also NetconfTopology.</p> <p><a href="https://git.opendaylight.org/gerrit/c/netconf/+/82678" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/c/netconf/+/82678</a> introduced this:</p> <p> </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">   <span class="code-keyword">default</span> void onDeviceReconnected(<span class="code-keyword">final</span> PREF netconfSessionPreferences, <span class="code-keyword">final</span> NetconfNode node);</pre> </div></div> <p>Which is fueled by passing down the NetconfNode – this needs to be pushed back to netconf-topology, so it follows proper up/down/reconnect lifecycle (via onDeviceDisconnected()). This should be possible, AFAICT.</p> <p> </p> <p>The next up unsolicited messages – for NETCONF this can only be a notification:</p> <p> </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">   void onNotification(DOMNotification domNotification); </pre> </div></div> <p>This should be a generic parameter of RemoteDeviceHandler – i.e. the format of unsolicited messages. It might be DOMNotification, assuming schemas, but at the end of the day this could as well be a message, which in turn comes to RemoteDeviceCommunicator specialization, which would naturally be a NetconfNotification!</p> <p> </p> <p>The thing is: the schemaless case of using org.w3c.Document is already handled by raw NetconfMessage, which begs the question, what is the key driver behind the use case. And it really is for netconf-topology to have:</p> <p> </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"><span class="code-keyword">final</span> RemoteDevice&lt;NetconfSessionPreferences, NetconfMessage, NetconfDeviceCommunicator&gt; device; </pre> </div></div> <p>and having a NetconfDeviceCommunicator working on top of that. The interaction with services then around back to NetconfDeviceSalFacade, which has onTopologyDeviceConnected() – which reflects back the services received on RemoveDeviceHandler callback. Note that onTopologyDeviceConnected() is again a leak of "topology" concept, but at this particular it should be called "onMountPointConnected". RemoteDeviceId is the key offender here: at the end of the day, this should be interface only YangInstanceIdentifier (and perhaps InetAddress, which is low-enough of a concet), as that is what we need to talk to DOMMountPointService – so topology-netconf should be filling out this part of RemoteDeviceId:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">    <span class="code-keyword">private</span> RemoteDeviceId(<span class="code-keyword">final</span> <span class="code-object">String</span> name) {         <span class="code-keyword">this</span>.name = requireNonNull(name);         topologyPath = DEFAULT_TOPOLOGY_NODE.node(NodeIdentifierWithPredicates.of(Node.QNAME, NODE_ID_QNAME, name));         key = <span class="code-keyword">new</span> NodeKey(<span class="code-keyword">new</span> NodeId(name));         topologyBindingPath = DEFAULT_TOPOLOGY_IID.child(Node.class, key);     } </pre> </div></div> <p>There might be more, but really, sal-netconf-connector is the binding between netconf-api and mdsal-dom-api – it must not depend on topology model in any shape or manner.</p> <p>Circling back for a minute on the grand scheme of things: sal-netconf-connect has multiple parts, which perhaps should split out to multiple components (but not now!). This is:</p> <ol> <li>setting up the device for use with DOMService APIs, then</li> <li>passing the lifecycle baton back to the user (i.e. netconf-topology) via RemoteDeviceHander.onDeviceConnected(), then</li> <li>supporting that user in binding that device to DOMMountPointService</li> </ol> <p>This means onDeviceConnected() does not break down all the services available in terms of individual DOMServices, but rather a generic handle (i.e. a sealed interface) with perhaps known specializations (as hinted by RemoteDeviceRpcs in above proposal), but really encapsulating everything but the session preferences. That sealed interface will be reflected back to us in step 3) which when we make sense of it.</p> <p>Hence all of the possibilities in RemoteDeviceHandler.onDeviceConnected() need to be refactored a single method:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">void onDeviceConnected(PREF netconfSessionPreferences, RemoteDeviceAccess access); </pre> </div></div> <p>I think we can safely specialize PREF to NetconfSessionPreferences, as there no other specializations. RemoteDeviceAccess is that sealed interface, which gets passed back to NetconfDeviceSalFacade and it will then make a decision what DOMServices to instantiate from that.</p> <p>So let's break this down into multiple subtask to focus our effort.</p> <p> </p> <p> </p> <p>This issue is flushing out a ton of technical debt w.r.t layering of information and control bits. At the end of the day sal-netconf-connector needs to be provide crisp components without being explicitly tied to netconf-topology.</p> <p> </p> Blocks MDSAL-541 Issue split NETCONF-925 Relates MDSAL-542 NETCONF-916 NETCONF-915 NETCONF-912 NETCONF-923 NETCONF-924 NETCONF-920 NETCONF-914 NETCONF-930 Development Rank 0|i03s3b: