The candidate datastore is described in the NETCONF standard RFC 6241 under section 8.3.
The candidate datastore is used to store configuration prior to committing it to the running datastore. This helps users edit and validate large amounts of configuration without impacting the running database and therefore without impacting the system.
For the candidate datastore to be enabled, the NETCONF server has to support the :candidate capability.
In ConfD, the candidate datastore is enabled by default. To control where the candidate database resides, you can specify this explicitly in confd.conf.
<!-- The 'candidate' is a shared, named alternative configuration database which can be modified without impacting the running configuration. Changes in the candidate can be commit to running, or discarded. Enable this if you want your users to use this feature from NETCONF, CLI or WebGUI, or other agents. --> <candidate> <enabled>true</enabled> <!-- By default, confd implements the candidate configuration without impacting the application. But if your system already implements the candidate itself, set 'implementation' to 'external'. --> <!--implementation>external</implementation--> <implementation>confd</implementation> <storage>auto</storage> <filename>./confd_candidate.db</filename> </candidate>
You can also configure your system to use an external database as the candidate datastore by setting the implementation field to “external”.
In order to enable the candidate capability for NETCONF, use the capability configuration in confd.conf:
<capabilities> <!-- enable only if /confdConfig/datastores/candidate is enabled --> <candidate> <enabled>true</enabled> </candidate> ...
Once the candidate capability is enabled, you can send NETCONF edit-config RPC requests toward the candidate and it won’t take effect till you send the commit RPC; Data will be stored in a candidate datastore file and will persist till a commit is received by the server to write the candidate content to the running datastore.