In my design, there are some new fxs files and I do in service upgrade. After the upgrade completed (succeeded), I can see the expected schema shown using confd_cli.
When I try to lock the confd candidate datastore, I keep getting the error response:
There is NO changes in confd.conf about before and after upgrade. The only changes in confd.conf is adding new load path. I also try to restart confd. But I will still get the same error response.
Any idea why confd keep complaining “capabilities-changed” ?
If you do such an upgrade, at least for YANG 1 modules, the <capabilities> as reported in the NETCONF <hello> message will have changed. I’m not clear on whether this is specified in an RFC, but in any case the idea with the capabilities-changederror is to inform the client that the capabilities have changed since it received the <hello> message from the server - the implication is that the client should terminate the current session and start a new one, to get the current capabilities. Do you get the error even in a session that is started after the upgrade has completed?
Is this restart done without doing a data model upgrade?
If it keeps complaining across restarts without upgrade, or in new sessions started after the upgrade has completed, it would be a bug - but it seems to me that it’s highly unlikely that this behavior exists. Otherwise, I believe it is working as designed.