[NETCONF-82] Mounted data store operations using legacy API fail in Lithium

Fri, 15 Mar 2019 22:22:15 +0000

There appears to have been a change in the Netconf operations for mounted stores from Helium to Lithium when using the legacy API. We have actually conversed on this issue with Maros on a previous occasion where it was suggested to use the current API. Nevertheless, given the change of behaviour we can see this as a bug, so I provide some detail. The Lithium code appears to send a netconf <lock> for operations executed on the store, including writes and reads. I.e. For the for the following pseudo code:
transaction = Mountpoint.beginTransaction()
Transaction.readConfigurationData()
Transaction.putConfigurationData;
Transaction.putConfigurationData;
Transaction.commit.

A lock is acquired at step 2 and also attempted at step 3 and 4. The latter two attempts fail, with a lock acquisition error.

{intlabVPP}: Sending message <rpc message-id="m-15" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>

2015-09-30 02:51:31,677 | TRACE | oupCloseable-7-2 | NetconfDeviceCommunicator | 325 - org.opendaylight.controller.sal-netconf-connector - 1.2.0.Lithium-00001-SNAPSHOT | Finished sending request <rpc message-id="m-15" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>

2015-09-30 02:51:31,698 | DEBUG | oupCloseable-7-2 | NetconfDeviceCommunicator | 325 - org.opendaylight.controller.sal-netconf-connector - 1.2.0.Lithium-00001-SNAPSHOT | RemoteDevice{intlabVPP}

: Message received <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-15">
<ok/>
</rpc-reply>

{intlabVPP}: Matched request: <rpc message-id="m-15" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>
to response: <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-15">
<ok/>
</rpc-reply>

2015-09-30 02:51:31,698 | TRACE | oupCloseable-7-2 | KeepaliveSalFacade | 325 - org.opendaylight.controller.sal-netconf-connector - 1.2.0.Lithium-00001-SNAPSHOT | RemoteDevice{intlabVPP}

{intlabVPP}: Scheduling next keepalive in 120 SECONDS
2015-09-30 02:51:31,698 | TRACE | oupCloseable-7-2 | NetconfRpcFutureCallback | 325 - org.opendaylight.controller.sal-netconf-connector - 1.2.0.Lithium-00001-SNAPSHOT | RemoteDevice{intlabVPP}

{intlabVPP}: Sending message <rpc message-id="m-16" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0" ns0:type="subtree">
<interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"/>
</filter>
</get>
</rpc>

2015-09-30 02:51:31,701 | TRACE | oupCloseable-7-2 | NetconfDeviceCommunicator | 325 - org.opendaylight.controller.sal-netconf-connector - 1.2.0.Lithium-00001-SNAPSHOT | Finished sending request <rpc message-id="m-16" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0" ns0:type="subtree">
<interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"/>
</filter>
</get>
</rpc>

2015-09-30 02:51:31,721 | DEBUG | oupCloseable-7-2 | NetconfDeviceCommunicator | 325 - org.opendaylight.controller.sal-netconf-connector - 1.2.0.Lithium-00001-SNAPSHOT | RemoteDevice{intlabVPP}

: Message received <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-16">
<data>
<interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>GigabitEthernet2/0/1</name>
<type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
<phys-address>f4:4e:05:21:aa:1d</phys-address>
<statistics>
<in-octets>0</in-octets>
<in-unicast-pkts>0</in-unicast-pkts>
<in-broadcast-pkts>0</in-broadcast-pkts>
<in-multicast-pkts>0</in-multicast-pkts>
<in-discards>0</in-discards>
<in-errors>0</in-errors>
<in-unknown-protos>0</in-unknown-protos>
<out-octets>0</out-octets>
<out-unicast-pkts>0</out-unicast-pkts>
<out-broadcast-pkts>0</out-broadcast-pkts>
<out-multicast-pkts>0</out-multicast-pkts>
<in-errors-no-buf xmlns="http://www.cisco.com/yang/cisco-vpp">0</in-errors-no-buf>
<in-errors-miss xmlns="http://www.cisco.com/yang/cisco-vpp">0</in-errors-miss>
<out-discards-fifo-full xmlns="http://www.cisco.com/yang/cisco-vpp">0</out-discards-fifo-full>
</statistics>
</interface>
<interface>
<name>local0</name>
<type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:softwareLoopback</type>
<admin-status>down</admin-status>
<oper-status>down</oper-status>
</interface>
</interfaces-state>
</data>
</rpc-reply>

{intlabVPP}: Matched request: <rpc message-id="m-16" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0" ns0:type="subtree">
<interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"/>
</filter>
</get>
</rpc>
to response: <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-16">
<data>
<interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>GigabitEthernet2/0/1</name>
<type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
<phys-address>f4:4e:05:21:aa:1d</phys-address>
<statistics>
<in-octets>0</in-octets>
<in-unicast-pkts>0</in-unicast-pkts>
<in-broadcast-pkts>0</in-broadcast-pkts>
<in-multicast-pkts>0</in-multicast-pkts>
<in-discards>0</in-discards>
<in-errors>0</in-errors>
<in-unknown-protos>0</in-unknown-protos>
<out-octets>0</out-octets>
<out-unicast-pkts>0</out-unicast-pkts>
<out-broadcast-pkts>0</out-broadcast-pkts>
<out-multicast-pkts>0</out-multicast-pkts>
<in-errors-no-buf xmlns="http://www.cisco.com/yang/cisco-vpp">0</in-errors-no-buf>
<in-errors-miss xmlns="http://www.cisco.com/yang/cisco-vpp">0</in-errors-miss>
<out-discards-fifo-full xmlns="http://www.cisco.com/yang/cisco-vpp">0</out-discards-fifo-full>
</statistics>
</interface>
<interface>
<name>local0</name>
<type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:softwareLoopback</type>
<admin-status>down</admin-status>
<oper-status>down</oper-status>
</interface>
</interfaces-state>
</data>
</rpc-reply>

2015-09-30 02:51:31,732 | TRACE | lt-dispatcher-27 | WriteCandidateTx | 325 - org.opendaylight.controller.sal-netconf-connector - 1.2.0.Lithium-00001-SNAPSHOT | RemoteDevice{intlabVPP}

{intlabVPP}: Sending message <rpc message-id="m-17" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>

2015-09-30 02:51:31,733 | TRACE | oupCloseable-7-2 | NetconfDeviceCommunicator | 325 - org.opendaylight.controller.sal-netconf-connector - 1.2.0.Lithium-00001-SNAPSHOT | Finished sending request <rpc message-id="m-17" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>

2015-09-30 02:51:31,735 | DEBUG | oupCloseable-7-2 | NetconfDeviceCommunicator | 325 - org.opendaylight.controller.sal-netconf-connector - 1.2.0.Lithium-00001-SNAPSHOT | RemoteDevice{intlabVPP}

: Message received <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-17">
<rpc-error>
<error-type>protocol</error-type>
<error-tag>lock-denied</error-tag>
<error-severity>error</error-severity>
<error-info>
<session-id>15</session-id>
</error-info>
</rpc-error>
</rpc-reply>

{intlabVPP}

: Matched request: <rpc message-id="m-17" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>
to response: <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-17">
<rpc-error>
<error-type>protocol</error-type>
<error-tag>lock-denied</error-tag>
<error-severity>error</error-severity>
<error-info>
<session-id>15</session-id>
</error-info>
</rpc-error>
</rpc-reply>

OpenDaylight JIRA

[NETCONF-82] Mounted data store operations using legacy API fail in Lithium