Candidate Configuration store lock
Candidate configuration store is shared across all the NetConf clients. Client application must acquire lock if they want to provision the device without other client's hindrance
NetConf Client 1: locks candidate configuration store.
yangcli ocnos@127.1> lock target=candidate
RPC OK Reply 1 for session 4:
NetConf Client 2: attempts to acquire the lock now, which leads to an access-denied error.
yangcli ocnos@127.1> lock target=candidate
RPC Error Reply 1 for session 5:
rpc-reply {
rpc-error {
error-type protocol
error-tag lock-denied
error-severity error
error-app-tag no-access
error-message 'lock denied'
error-info {
session-id 0
error-number 268
}
}
}
Now error “access-denied” is received by NetConf client 2 when it attempts to provision the device.
yangcli ocnos@127.1> edit-config config=@/home/ospf_payload.xml
Filling list /ospfv2:
RPC Error Reply 3 for session 4:
rpc-reply {
rpc-error {
error-type application
error-tag in-use
error-severity error
error-app-tag no-access
error-path /nc:rpc/nc:edit-config/nc:config
error-message 'config locked'
error-info {
error-number 301
}
}
}
NetConf client 1 releases the lock
yangcli ocnos@127.1> unlock target=candidate
RPC OK Reply 2 for session 4:
NetConf client 2 can acquire the lock now, since no other client is holding the lock.
yangcli ocnos@127.1> lock target=candidate
RPC OK Reply 2 for session 5:
Last modified date: 06/08/2023