The YANG modeling language provides a means to distinguish which data is configuration (config true) and which data is operational (config false). Operational data may be counters and other types of rapidly changing values, or they can be infrequently changing values such as the operational state of an interface.
For operational data, you have two choices for how to supply the values. One is to use the Data Provider API and the other is to store the operational data in CDB. A way of deciding which way to supply the operational data values is to decide how frequently the values are changing. For rapidly changing values, such as packet sent or received counters for interfaces, it is much better to use the Data Provider API, and to retrieve the counters from the ASIC or network processor on demand as a request comes in via a northbound interface such as NETCONF, rather than constantly reading the counters and storing them in CDB. For less frequently changing operational data values, it is possible to use the Data Provider API, but an alternative is to store the data in CDB.
If you want to store the operational data in CDB, you still indicate the data is operational in your YANG model with config false, but you add the additional Tail-f annotation tail-f:cdb-oper. This annotation lets ConfD know this operational data is to be kept in CDB. You can then use functions such as cdb_set_elem() and other functions to set the value in CDB. Look in section 6.8 of the ConfD User’s Guide and the confd_lib_cdb manpage for more details on the APIs for storing operational data in CDB. There are also a pair of examples in the directory $CONFD_DIR/examples.confd/cdb_oper
One advantage to storing operational data in CDB is that when a request comes from a northbound interface, such as NETCONF get RPC, ConfD is able to return the value by fetching it from CDB, instead of making a call to your application’s callback function if you are using the Data Provider API.