[NETCONF-130] Netconf connector not safe in 3-node cluster Created: 25/Jan/16  Updated: 15/Mar/19  Resolved: 01/Feb/16

Status: Resolved
Project: netconf
Component/s: netconf
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Vratko Polak Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 5079

 Description   

It seems like odl-netconf-connector-ssh feature in Beryllium (and Boron) is not ready for cluster deployment, as it can lead to "server unhealthy" error state.

See [0] for recent example, where the reason is:

2016-01-22 10:54:10,205 | WARN | lt-dispatcher-18 | SimpleShardDataTreeCohort | 154 - org.opendaylight.controller.sal-distributed-datastore - 1.4.0.SNAPSHOT | Store Tx member-3-chn-2-txn-1: Conflicting modification for path /(urn:opendaylight:inventory?revision=2013-08-19)nodes/node/node[

{(urn:opendaylight:inventory?revision=2013-08-19)id=controller-config}

].
2016-01-22 10:54:10,206 | ERROR | lt-dispatcher-44 | LocalThreePhaseCommitCohort | 154 - org.opendaylight.controller.sal-distributed-datastore - 1.4.0.SNAPSHOT | Failed to prepare transaction member-3-chn-2-txn-1 on backend
OptimisticLockFailedException

{message=Optimistic lock failed., errorList=[RpcError [message=Optimistic lock failed., severity=ERROR, errorType=APPLICATION, tag=resource-denied, applicationTag=null, info=null, cause=org.opendaylight.yangtools.yang.data.api.schema.tree.ConflictingModificationAppliedException: Node was created by other transaction.]]}

Of course, there is odl-netconf-clustered-topology feature to be used with cluster, but that does not initiate the self-connection (controller-config device) that is needed for users who want to re-configure ODL in runtime using restconf.

Is there a way to use netconf-connector functionality in 3-node cluster?

[0] https://jenkins.opendaylight.org/releng/job/controller-csit-verify-3node-clustering/54/consoleFull

 Comments   
Comment by Tomas Cere [ 01/Feb/16 ]

This is a limitation of cfg subsystem and CDS.
Since the controller-config loopback connection corresponds to a different
entity on each node(separate netconf server per node) the operational data of
the connector's should not be clustered since as you can see the connector's
are overwriting each other's data.

Since the controller-config connection is just a preconfigured netconf
connector that connects to the cfg subsystem netconf server on localhost
a possible workaround is to manually start a clustered connector for each
cfg-subsystem server in the cluster. You would then have to differentiate these
with different node id's(ex. controller-config-node1). You will also for example
be able to post configuration meant for cfg subsystem on other nodes to a single node.

Comment by Vratko Polak [ 01/Feb/16 ]

So the title of this Bug is the expected behavior.
Setting to WONTFIX; there is no official requirement to make netconf-connector cluster-proof, as there is odl-netconf-clustered-topology feature.

Wikipage for testers is created [0]. Is there an authoritative wikipage from netconf (or controller) project?

[0] https://wiki.opendaylight.org/view/Integration/Test/Cluster_Incompatible_Features#odl-netconf-connector

Generated at Wed Feb 07 20:14:14 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.