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-328 netconf <p>Or make odl-netconf-topology compatible with odl-netconf-clustered-topology somehow.</p> <p>Currently the two features are incompatible, i.e. causing CSIT failures when installed together. Currently the failures are prevented by removing both features from odl-integration-compatible-with-all, which means CSIT <del>all</del> jobs are not testing whether netconf features cause failures in non-netconf tests.</p> <p>Feature odl-netconf-topology may offer a slight preformance improvement in 1node setups, but other ODL projects may have cluster-compatible functionalities which would benefit from odl-netconf-clustered-topology.</p> <p>Deprecating odl-netconf-topology would allow for odl-netconf-cluster-topology moving back to odl-integration-compatible-with-all.</p> <p>Operating System: All<br/> Platform: All</p> NETCONF-328

Deprecate odl-netconf-topology in Carbon

Bug Resolved Won't Do Unassigned Vratko Polak Fri, 9 Dec 2016 14:10:57 +0000 Fri, 15 Mar 2019 22:22:34 +0000 Tue, 10 Oct 2017 14:28:43 +0000 netconf 0 4 <p>Hi Vratko,</p> <p>It's a good idea, but I think this should discussed more in detail.</p> <p>If we deprecate (and eventually remove) odl-netconf-topology, we will loose ability to spawn "non-clustered" NETCONF connections. Are we sure that this is something unnecessary?</p> <p>Also the odl-netconf-topology is better documented, tested and supports more functionality than odl-netconf-clustered-topology does (currently, notification support for example).</p> <p>Making these two features compatible would require some API changes in YANG models, but maybe this is better option than deprecating and removing odl-netconf-topology completely.</p> <p>&gt; supports more functionality than odl-netconf-clustered-topology does<br/> &gt; (currently, notification support for example).</p> <p>Oh, I was not aware of that.<br/> I believe this Bug should be postponed till odl-netconf-clustered-topology supports notifications (and other important features not supported yet).</p> <p>&gt; Making these two features compatible would require some API changes in YANG models</p> <p>Jakub, can you say more about those API changes in YANG models? Do you have a well defined idea of where this should be done? Or at least where to look at? With a little a guidance, I'm willing to look into this.</p> <p>I dont think we should get rid of the nonclustered one, there are valid use cases which might want explicit nonclustered connectors, we should however make the list which is used for the config/oper data configurable or have each implementation govern its own list.</p> <p>&gt; valid use cases which might want explicit nonclustered connectors</p> <p>Is there a design proposal on how that should work (in cluster)? I do not believe current odl-netconf-topology cluster behavior fits any reasonable proposal.</p> <p>Another issue is that users might want to use both local-member and cluster-wide connectors at the same time, which is currently not possible as both features listen to the same topology-netconf data.</p> <p>I would imagine an extension to odl-netconf-clustered-topology can be implemented, which would allow users to specify list of members allowed to handle the connection.</p> <p>Would it be possible to develop a unified design (and then deprecate the current behavior) in Oxygen?</p> Development External issue ID 7334 External issue URL Issue Type ODL SR Target Milestone Rank 0|i01xv3: