Details
-
Bug
-
Status: Resolved
-
Resolution: Duplicate
-
Helium
-
None
-
None
-
Operating System: All
Platform: All
-
2560
Description
Current write sequence follows these steps(candidate supported):
- edit(candidate)
- commit
But it is required to use locking and also detect concurrent edits for shared datastores (using discard changes).
Expected canonical write for devices supporting only writable running capability:
- lock running or fail
- edit running (unlock on fail)
- unlock running
supporting only candidate:
- lock candidate
- if lock fails, try to discard changes
- if discard fails, fail
- if discard succeeds, lock candidate
- if lock fails, fail
- if lock fails, try to discard changes
- edit candidate (discard-changes + unlock on fail)
- commit
- unlock candidate
supporting both writable running and candidate:
- lock running or fail
- SAME AS FOR CANDIDATE ONLY
- unlock running
Attachments
Issue Links
- duplicates
-
CONTROLLER-1048 Netconf connector assumes candidate=running on transaction start
- Resolved