A project using ConfD must choose a valid combination of datastores to support. Which combination to choose depends on the system resources available on the device, and which characteristics the end-product should have.
The following is a list of valid combinations:
running in read-write mode, no startup, no candidate:
• A single, non-volatile running datastore is used.
• Once changes are written to the running datastore, they are persistent, and cannot automatically be rolled back.
• The ConfD client application needs to react to changes to the database. If CDB is used, this means that the application must use the subscription mechanism.
running in read-write mode and startup:
• startup is stored in non-volatile memory, and running in read-write RAM.
• The ConfD client application needs to be written in such a way that it reacts to changes to the database. If CDB is used, this means that the application must use the subscription mechanism.
running in read-write mode and candidate:
• Both running and candidate are stored in non-volatile memory.
• NOTE: This combination is NOT RECOMMENDED. When a manager reconfigures a node that has the candidate and also read-write running, the manager can never know that running is up to date with the candidate and must thus always (logically) copy running to the candidate prior to modifying the candidate. This introduces unnecessary overhead, and makes automation more complicated.
• The ConfD client application needs to react to changes to the database. If CDB is used, this means that the application must use the subscription mechanism.
• In this mode, running can be modified without going through the candidate. This means that a client that wishes to work with the candidate may need to copy running into the candidate, to ensure that no changes to running are lost when the candidate is committed.
running in writable-through-candidate mode and candidate (as described in the Candidate Datastore post):
• Both running and candidate are stored in non-volatile memory, but the candidate can efficiently be implemented as a diff against running.
• The ConfD client application needs to react to changes to the database. If CDB is used, this means that the application must use the subscription mechanism.
• In this mode, all changes always go through the candidate, so a client does never have to copy running to candidate in order to not lose any data.
ConfD ensures that running and startup are always consistent, in the sense that the validation constraints defined in the data model hold. The candidate is allowed to be temporarily inconsistent, but if it is committed to running, it must be valid.
ConfD by default implements the datastores chosen in CDB. However, ConfD can also be configured to use an external database. If an external database is used, this database must implement the running and startup datastores if applicable. If the candidate is used, it may be implemented with CDB or as an external database.