I’ve use case where I want to rollback the configs if maapi.candidateCommit() is failed.
Here are the steps we perform.
Push configs without candidate db lock
Transaction completed successfully (applyTransaction and finishTransaction)
Execute Mappi.commitCandidate
While executing Maapi.candidateCommit, getting some access denied error due to nacm rule configured to deny for a particular path. Now due to this we fail the request, but configs are still present in candidate DB. We can use candidateReset method to copy the running into Candidate DB. But we don’t know what other configs are present in candidate DB as we don’t lock it before pushing configs.
Is there a way to rollback only a specific transaction configs and keep the rest in candidate?
Also is there a way an api to copy running into Candidate without discarding existing changes in Candidate?
ConfD’s candidate + confirmed commit implementation is described by the NETCONF RFC 6241:
Quoting the RFC:
The candidate configuration can be shared among multiple sessions.
Unless a client has specific information that the candidate
configuration is not shared, it MUST assume that other sessions are
able to modify the candidate configuration at the same time. It is
therefore prudent for a client to lock the candidate configuration
before modifying it.
Regarding confirmed commit:
For shared configurations, this feature can cause other configuration
changes (for example, via other NETCONF sessions) to be inadvertently
altered or removed, unless the configuration locking feature is used
(in other words, the lock is obtained before the
operation is started). Therefore, it is strongly suggested that in
order to use this feature with shared configuration datastores,
configuration locking SHOULD also be used.
No
No
Implementing some external database that does what you describe is not recommended if you want to stay RFC 6241 compliant. If you want to diverge from the RFC, you are on your own.
Looks like ConfirmedCommit also rollbacks all other configs (configs pushed by some other client) present in candidate DB?
Is ConfirmedCommit and candidateReset operations produces the same result?