Reading of YANG path from device fails sometimes with "source and destination list must be unique"
Sometimes if you ask the controller to get a path from a network element, e.g. "/" it fails while unmarshaling the devices response into the model currently in the database with the f9ollowing error:
source and destination lists must be unique, got src: [0xc0005aca00], dst: [0xc004b20278 0xc004b20290]
The fields which have the error can change. here a a few examples:
Sometimes there is just a blank too much:
[ /usr/bin/Cli]
[ /usr/bin/Cli]
Sometimes values are doubled:
[systemd.setenv=SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 systemd.setenv=INTFTYPE=eth systemd.setenv=MAPETH0=1 systemd.setenv=MGMT_INTF=eth0 systemd.setenv=CEOS=1 systemd.setenv=EOS_PLATFORM=ceoslab systemd.setenv=container=docker systemd.setenv=ETBA=1]
[systemd.setenv=CEOS=1 systemd.setenv=EOS_PLATFORM=ceoslab systemd.setenv=container=docker systemd.setenv=ETBA=1 systemd.setenv=SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 systemd.setenv=INTFTYPE=eth systemd.setenv=MAPETH0=1 systemd.setenv=MGMT_INTF=eth0 systemd.setenv=SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 systemd.setenv=INTFTYPE=eth systemd.setenv=MAPETH0=1 systemd.setenv=MGMT_INTF=eth0 systemd.setenv=CEOS=1 systemd.setenv=EOS_PLATFORM=ceoslab systemd.setenv=container=docker systemd.setenv=ETBA=1]
Sometimes they are completely different:
[--system --address=systemd: --nofork --nopidfile --systemd-activation]
[-stayalive -pidfile /var/run/xinetd.pid --system --address=systemd: --nofork --nopidfile --systemd-activation]
[/usr/sbin/rasdfilter.sh],
[/mce_record:/ {gsub(/\0/,""); print; fflush();} /usr/sbin/rasdfilter.sh]
The errors share one thing, they are all happening in the "args" path of a running process.
To test it yourself load the following configs via the venv-manager: sts_demo.yaml sts_sdn_demo_broken.json
Then try to export it again, but uncomment the lines in the venv-manager, that read the path of a network element.