Roll back on Running data store

Hi All,

If rollback-on-error capability is not enabled and candidate data store is not enabled, what is the way to perform roll back on RUNNING data store when an edit operation fails.

Good question. Please read the section describing how the ConfD NETCONF server implements the rollback-on-error capability in “Chapter 15. The NETCONF Server” in the User Guide. TL;DR - ConfD always behaves as if the capability is enabled and <error-option> is set to rollback-on-error.

Hi Per,

Good to know that rollback-on-error is always enabled by ConfD. Suppose if I am doing multiple edits in one edit(bulk edit), does rollback works similar to single edit.

Thanks,

Not sure what you mean by “bulk edit” - each <edit-config> operation towards running corresponds to one ConfD transaction, and succeeds or fails in its entirety. If you do multiple <edit-config> in one NETCONF session, they succeed or fail independently. I.e. your second <edit-config> doesn’t fail “just because” your first one failed - but if may of course fail due to assuming that the first one succeeded, and attempting edits that are invalid when the first one failed.

Hi Per,

I plan to combine different entities edits into one edit. Like suppose if I need to edit both shelf and slot on a Network Element, I want to combine these both edits and perform one . If slot edit fails after shelf edit was successful(Assuming I am planning to send shelf edit first followed slot edit), since both edits are part of one , I assume the changes on the shelf would get rolled back. Is my understanding correct here?

Also, I have different question on locks. Do you recommend to perform global LOCK and UNLOCK on running data store here for operations. I have read in the user doc that ConfD has its own internal locks used for each operations. If so, then when do we really have the need to use global lock and unlock.

Thanks,

You keep talking about “edits” - what do you mean by that? It is not a term defined by the NETCONF spec. As I mentioned, it has an <edit-config> operation, but saying “combine two <edit-config> and perform one” doesn’t make any sense.

Hi Per,

I will do some testing myself to know about the edit-config operation. Can you let me know about the global lock/unlock behavior. Do you recommend to perform global LOCK and UNLOCK on running data store(when no candidate is supported) for edit-config operations. I have read in the user doc that ConfD has its own internal locks used for each edit-config operation. If so, then when do we really have the need to use global lock and unlock.

Thanks,
Aruna.

A ConfD transaction always takes a “transaction lock” for the duration of the VALIDATE - WRITE - PREPARED - COMMIT/ABORT states of the transaction (refer to the state machine diagram in Chapter 7 of the User Guide). This ensures that transaction commits are serialized, and I would say that this is sufficient for any single <edit-config> operation towards running. Taking a lock when only running is used can be motivated if the intent is to perform multiple <edit-config> operations (== transactions), and it is considered important that no other transaction commits “sneak in between” them - though I would also say that this is not a typical case.

When the candidate is used on the other hand, taking a lock on the candidate (and having running configured as writable-through-candidate), which is kept until the candidate is committed to running, is essential, since otherwise one session may end up attempting to commit candidate changes that have ben done by another session.

Thanks Per.
If I do multiple edit-config operations by taking a lock on running data store, and if any one edit-config operation fails, does ConFD roll back the other successful edit-config operations if I do unlock at the end of these edit-config operations. If not is there any equivalent operation(like discard changes in candidate store) I can use to go back to the state before lock.

Thanks,

No, that would be a serious violation of the NETCONF spec.

You could perhaps use ConfD’s “explicit” rollback functionality. But I think it would make more sense to do the intended modifications in a single <edit-config> - or actually use the candidate.