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:
<rpc-error>
<error-type>application
<error-tag>resource-denied
<error-severity>error
<error-app-tag>capabilities-changed
</rpc-error>
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.
I think what you mentioned is the reason cause issue. In the design, it looks like we keep using the existed session which is established before upgrade. But I need to double check.
After restart, I think the upgrade be done again since the design of backend service. But again I need double check.
Thank you very much. What you recommend gave a direction where I should start investigating!