I’ll take a stab at this common issue that there has been extensive chapters in books written about. See for example http://dataintensive.net/
The strategy you choose basically depends on your use-case, although there are some fundamental rules that apply to something like 99.9% of all use-cases.
For YANG based network management protocols such as NETCONF and RESTCONF, the NMDA RFC 8343 gives an introduction https://tools.ietf.org/html/rfc8342#section-1 to the problem you describe together with the objectives section in that RFC. https://tools.ietf.org/html/rfc8342#section-2
The section on the background is very valuable too https://tools.ietf.org/html/rfc8342#section-4
The appendixes give great guidelines to various use-cases.
As you will notice, that the device itself deletes config that a manager, e.g. a NETCONF client, has entered through a transaction makes automation of service deployments to devices/nodes very very hard. It breaks what the NETCONF standard address and makes automation significantly more complex to achieve.
Instead, your device/node should never delete configuration that a manager has set, and never set a transaction “partially”. See the “A” in “ACID” for example here: https://en.wikipedia.org/wiki/Database_transaction.
Without knowing anything about your use case, usually you have these options to choose from (or a combination) for configuration that may fail to be implemented by your device:
- If the transaction fail after the transaction’s “point-of-no-return”, leave the configuration as it is, and, for example, send an alarm to the manager that set the configuration so that the manager, e.g. NETCONF client become aware of the issue and can decide what to do.
- Test the new configuratio as part of the transaction, in for example ConfD’s validation and prepare phases, where you can still abort the transaction. Or even set the configuration in the prepare phase of the transaction, but if so, be prepared to also unset it if it is aborted by your device, but a loss of connection to the manager. or aborted by the manager.
- Implement the RFC 8343 NMDA intended and operational state datastores for the configuration that may fail.
- implement your own operational state by duplicating the YANG model for the configuration that may fail after commit, and use the *config true" configuration duplicated as “config false” nodes reflect the operational state. Appendix A of the YANG Hardware Management RFC is a nice, well described, example of such an implementation based on the hardware mgmt use-case. https://tools.ietf.org/html/rfc8348#appendix-A
So rule0: never touch/change the manager / client owned running(/intended) data store configuration. Instead, use verification phases of a transaction, alarms, and operational state data to reflect the operational status of the managers, e.g. NETCONF client, intended configuration