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-492 controller <p>Operating System: All<br/> Platform: All</p> CONTROLLER-492

MD-SAL netconf northbound

Improvement Resolved Done Maros Marsalek Tomas Olvecky Tue, 20 May 2014 09:38:56 +0000 Tue, 25 Jul 2023 08:23:47 +0000 Mon, 23 Feb 2015 12:14:34 +0000 netconf Thu, 19 Feb 2015 00:00:00 +0000 0 4 <p>Adding initial design notes:</p> <p>MDSAL - Netconf northbound ifc</p> <p>Tasks:<br/> 1. Implement Netconf -&gt; Md-sal mapper<br/> a. Implement base netconf ops<br/> a1. Implement get and get-config (complex subtree filtering required)<br/> I suggest splitting this into several pieces:<br/> 1.get and get-config – whole tree – simplest one<br/> 2. simple subtree filter – XML to instance identifier<br/> 3. advanced filtering (maybe not Lithium, will require additional design).</p> <p> a2. Implement edit config (same functionality as restconf patch required)<br/> a2.1. Commit/Discard-changes rpcs not an issue.<br/> a3. Lock/Unlock should not be an issue since this will be only candidate (no writable-running) and each client would get isolated transactions.<br/> a4. Validate + test option in edit-config.<br/> Will require better analysis how to hook up into MD-SAL lifecycle or small API changes.<br/> a5. Copy-config/Delete-config not supported most likely.<br/> Probably not in lithium</p> <p>2. Implement Netconf monitoring<br/> a. Entire monitoring could be reused from netconf-&gt;config-subsystem monitoring<br/> This will require design to reuse common monitoring parts for netconf-monitoring and<br/> restconf-monitoring<br/> Monitoring data should be stored in data broker – so you will be able to get restconf state<br/> via netconf and vice-versa.</p> <p>3. Implement notification support in netconf-impl<br/> a. Notification supports is not present at all. This requires changes of the SPIs and possibly APIs of netconf.</p> <p>Problems:<br/> 1. Dynamic nature of DomDataBroker. THe broker gets auto-updated after every schemaContext change, the netconf server will need to auto update as well. Current netconf clients do not really support dynamic netconf servers(servers that change the yang schemas) ? However once the ODL is up and running, the incomming clients would not experience the dynamic nature, since the controller will not change its features much.</p> <p>2. Invoking get rpc should return both config and operational data in one response. Does read from DomDataBroker return both the data ? Or will we need to merge both of them ? In that case, could we experience inconsistencies between operational and config due to 2 separated reads ?</p> <p> It is application responsibility to synchronize config / operational data tree (for now).</p> <p>3. How to read candidate ? It means reading the transaction opened for client that is performing an edit-config operation. Is this possible somehow ?</p> <p> Read from allocated MD-SAL transaction to particular client</p> <p>4. How to perform validation/testing of a transaction before its commitment ?</p> <p> Need to be analysed.</p> <p>Initial implementation of MD-SAL netconf northbound was merged into master branch</p> Blocks CONTROLLER-988 CONTROLLER-1123 CONTROLLER-1124 CONTROLLER-1125 Development External issue ID 1042 External issue URL Issue Type ODL SR Target Milestone Priority Rank 0|i02kqf: