Strange issue with inconsistency between sysrepocfg and netopeer2-server

[bbergquist0930]

The system has

root@tsx-100:~# sysrepoctl -V
sysrepoctl - sysrepo YANG schema manipulation tool, compiled with libsysrepo v2.2.60 (SO v7.14.20)
oot@tsx-100:~# netopeer2-server -V
netopeer2-server 2.1.59

What I am seeing is that from sysrepocfg I can see data in the running store:

root@tsx-100:~# sysrepocfg -X -d running -x /canoga-tsx-vcs:vc/vc-name
<vc xmlns="urn:canogaperkins:tsx:vcs">
  <internal-vc-id>2</internal-vc-id>
  <vc-name>foobar</vc-name>
</vc>
root@tsx-100:~# 

but If I start netopeer2-server and try the equivalent from netopeer2-cli, I don't see the same thing:

oot@tsx-100:~# ps ax | grep net
   31 ?        I<     0:00 [netns]
  481 ?        Ss     0:00 python3 /usr/bin/networkd-dispatcher -T -vvv
  545 ?        Ss     0:00 /lib/systemd/systemd-networkd
  962 pts/0    S+     0:00 grep net
root@tsx-100:~# netopeer2-server -d -t 30&
[1] 964
root@tsx-100:~# netopeer2-cli
> connect
root@localhost password: 
> get-data --datastore running --filter-xpath /canoga-tsx-vcs:vc/vc-name
DATA
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"/>

> get-data --datastore startup --filter-xpath /canoga-tsx-vcs:vc/vc-name
DATA
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
  <vc xmlns="urn:canogaperkins:tsx:vcs">
    <internal-vc-id>2</internal-vc-id>
    <vc-name>foobar</vc-name>
  </vc>
</data>

> 

The data can be retrieve from the startup datastore through netopeer2-server but the running datastore does not see the data.

Anything that I could look at would be most useful.

[bbergquist0930]

A second test I did is this. I stop the netopeer2-server. I then did rm -rf /dev/shm/sr_* and tried the exact same sequence of steps and this time the configuration is seen when accessed through netopeer2-cli. Maybe that is a clue.

[michalvasko]

I am not sure what the problem may be but if you provide steps to reproduce it, I should figure it out. So start with make sr_clean and then include all the commands until you get a response without data in netopeer2-cli. You also should not be using root for all the commands but it should work, nevertheless.

[bbergquist0930]

I will try to get a small reproducable case. Of course like everything there are issues:

• this is on an embedded device
• the device is being configured by an application through netopeer2-server
• the changes are applied to the candidate datastore
• the changes being applied are through a confirmed commit with timeout that is then confirmed
• the running datastore is then copied to the startup datastore

I understand needing a small reproducable test case to find the issue. I will try to reproduce this in:

• an non-embedded straight linux environment
• with a small YANG model and set of changes