Copy-config vs discard-changes

[Aruna]

Hi,

How safe it is not to use copy-config for candidate data supported devices with direct running writable disabled. I would like to know the behavior from standard perspective, and also if there is any Confd specific behavior, please highlight behavior for my understanding in your response.

I have been using copy-config for all my edit-config operations on the candidate data store supported devices, but now I am thinking to avoid this(for performance reasons) if running data store writable only through candidate data store.

Here the steps we perform involved for an edit-config operation on CANDIDATE data store enabled devices,
• Lock CANDIDATE data store
• copy-config from RUNNING to CANDIDATE
• Perform edit-config on CANDIDATE data store
• Perform commit
• Unlock CANDIDATE data store

Now my questions are,

1. If there are any uncommitted changes from a session with lock acquired, does unlock would discard changes automatically similar to using discard-changes explicitly or another client need to use discard-changes explicitly?
2. if there are any uncommitted changes from “config shared” mode, I assume lock will fail for any other client?

Thanks,

[waitai]

@Aruna

If there are any uncommitted changes from a session with lock acquired, does unlock would discard changes automatically similar to using discard-changes explicitly or another client need to use discard-changes explicitly?

The <unlock> operation will automatically discard any uncommitted changes.

@Aruna

if there are any uncommitted changes from “config shared” mode, I assume lock will fail for any other client?

Yes, the <lock> operation will fail if there are any outstanding changes.