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-945 netconf <p>netconf-impl contains classes (in the .osgi) package, which really are related to netconf-server. These get activated in mdsal-netconf-impl via blueprint. Separate these classes out into an OSGi DS-driven netconf-server package. Eliminate blueprint from mdsal-netconf-impl, leaving it empty, but retain dependency compatibility by depending on netconf-server.</p> <p>Note netconf-server should live in /protocol directory.</p> <p>Based on below, this issue deals with just rename and movement of code. The blueprint stuff will be dealt with separately.</p> NETCONF-945

Rename netconf-impl to netconf-server

Task Medium Resolved Done Robert Varga Robert Varga pt Mon, 23 Jan 2023 20:24:58 +0000 Tue, 2 May 2023 09:03:03 +0000 Tue, 2 May 2023 09:03:03 +0000 6.0.0 netconf 0 2 <p>there are issues:</p> <ul> <li><em>osgi</em> package artifacts cannot be extracted from <em>netconf-impl</em> module because these artifacts are not isolated<br/> and having same module dependencies; maven artifacts cannot have cross-dependencies</li> <li><em>osgi</em> package is not the only containing server related artifacts - majority of module top level<br/> artifacts are named like NetconfServer* and listed as osgi services in the blueprint</li> </ul> <p>due there is almost everything to extract, suggested</p> <ul> <li>renaming modules <em>netconf-impl</em> -&gt; <em>netconf-server,</em>  <em>mdsal-netconf-impl</em> -&gt; <em>mdsal-netconf-server</em></li> <li>packages renaming <em>impl</em> -&gt; <em>server</em>, <em>osgi</em> -&gt; <em>services</em> (or move artifacts to upper level)</li> </ul> <p>Okay, fair enough. Let's punt this for 6.0.x, as renaming things will break users.</p> <p> </p> <p>So going through the motions of migration, there is a metric ton of clean ups here. The problem is that client-side and server-side APIs are not separated and tucked in netconf-api (which hosts NetconfMessage), netconf-notifications-api and netconf-mapping-api (which both are server-side things).</p> <p>We really want to separate the generic, client-side and server-sides, as otherwise we won't be able to make out what is required where. This essentially means that all the server-side APIs need to be rehosted to org.opendaylight.netconf.server.api sub-packages, to make the dependencies obvious.</p> <p>There is additional wrinkle I came across, which is that we do not have proper NetconfMessage specializations for anything except &lt;hello/&gt; and &lt;notification/&gt;. This muddles which layer netconf-api is really is about:</p> <ul class="alternate" type="square"> <li>NetconfSession is quite obviously Transport layer</li> <li>NetconfMessage is obviously (with HelloMessage and NotificationMessage) at Messages layer</li> </ul> <p>But then we lack RpcMessage and RpcReplyMessage &#8211; and this ends up being checked all over the place. One notable problem netconf.utll.messages.SubtreeFilter, which operates on plain documents, but performs checks for &lt;get&gt; and &lt;get-config&gt; operations &#8211; which indicates it operates on Operations layer, without every employing the underlying safety of the Messages layer.</p> <p>As a further wrinkle we have netconf.api.monitoriing, which is obviously tied to a specific YANG module, which in turn is a Content layer thing &#8211; and there for that we have the netconf-mapping-api, which deals with RPC mapping and netconf-notifications-api, which deals with Notification mapping &#8211; both of which are server-side things.</p> <p>Since the client-side of things only cares about Transport and Messages layer, netconf-api needs to only capture those layers &#8211; for now that is. The transport part of things is already being split into transport-api, hence once the dust settles, netconf-api is only about Messages layer and higher-layer concerns a purely a netconf-server thing.</p> Issue split NETCONF-951 Development Epic Link NETCONF-944 Rank 0|i04427: