This affects several CSIT tests. Usually, a test first configures peer to be active (ODL does not initiate connection) and then reconfigure it to be passive (ODL initiates connection).

Currently, the connection is not established [0] after such re-configuration.

Looking into the karaf.log [1] (the reconfiguration starts at 05:44:33,089), we see peer singleton to be closed and re-opened, but there are many suspicious lines in the log. The first exception is:

2017-08-14 05:44:33,230 | WARN | rd-dispatcher-32 | ShardDataTree | 257 - org.opendaylight.controller.sal-distributed-datastore - 1.6.0.SNAPSHOT | member-1-shard-default-operational: Store Tx member-1-datastore-operational-fe-0-chn-20-txn-1-0: Data validation failed for path /(urn:opendaylight:params:xml:ns:yang:bgp-rib?revision=2013-09-25)bgp-rib/rib/rib[

{(urn:opendaylight:params:xml:ns:yang:bgp-rib?revision=2013-09-25)id=example-bgp-rib}

].
org.opendaylight.yangtools.yang.data.api.schema.tree.ModifiedNodeDoesNotExistException: Node /(urn:opendaylight:params:xml:ns:yang:bgp-rib?revision=2013-09-25)bgp-rib/rib/rib[

{(urn:opendaylight:params:xml:ns:yang:bgp-rib?revision=2013-09-25)id=example-bgp-rib}

] does not exist. Cannot apply modification to its children.

It is not clear to me, whether the bug is in BGP code (accessing data with wrong assumptions) or in controller/mdsal code (singleton service executing open and close operation in unexpected order).

[0] https://logs.opendaylight.org/releng/jenkins092/bgpcep-csit-1node-userfeatures-only-nitrogen/113/log.html.gz#s1-s4-t12-k3
[1] https://logs.opendaylight.org/releng/jenkins092/bgpcep-csit-1node-userfeatures-only-nitrogen/113/odl1_karaf.log.gz