okmine123
commented
7 years ago Sorry, seems it is only happened in my porting to buildroot. Not happened in the centos x86 server. I guess my porting to the buildroot has lead something wrong not to make the 'candidate' and 'running' equal.
Dear Maintainer,
I don't know it is bug or just it is the spec should like that. When the netopeer-server start, does it should make the candidate and running space all the nodes same in the initial time?
After netopeer-server start run first time. I found the 'interfaces' yang model that the get-config candidate is vacant. But running space is listed all the interfaces.
If my first command is 'commit', the callbacks would think it is commiting a vacant node and with 'op' the 'REM' operation. Then all the nodes in the 'running' space would removed. I asking this question to make me understanding the candidate space clearly. 'commit' operation try to make 'candidate' space totally same with with 'running' space. If so, I need to send command 'discard-changes' first when the first time connect the server to make the 'candidate' space and 'running' space totally same, then edit-config any of the interfaces in candidate. then 'commit' in the end. If I mix operate the edit-config candidate and edit-config running. There is problem. I have to add 'discard-changes' follow after the 'edit-config running' to make 'candidate' adn 'running' all the same. Then start to 'edit-config candidate'. An example steps to explain what do I say: discard-changes //copy 'running' to 'candidate' edit-config candidate commit //copy 'candidate' to 'running' edit-config running edit-config running discard-changes //copy 'running' to 'candidate' edit-config candidate commit ......
So my question is my understanding is right or not? If yes, so the netopeer-server should has a bug in the initial time not make 'candidate' and 'running' same, is it correct? Expect reply.
Thanks!