In the 1-2-3-start-query-model example all data is configuration data, i.e. no operational data (config false) is defined in the YANG data model. Hence, a NETCONF <GET> will not trigger the application in this example.
The setup is something like this:
+-------------+
| NETCONF/CLI | ConfD Compiler
| view | <---------------------
+-------------+ |
| +----------+
| 1-1 mapping | YANG |
| | model |
+------------+ +----------+
| CDB | ConfD Compiler |
| data store | <---------------------
+------------+
|
| CDB subscribe/read
|
+------------+
+-------------| |
| application |-+
+-------------+
When performing a NETCONF <GET> running the 1-2-3 example, e.g. typing
$ netconf-console cmd-get-all.xml
we will retrieve the example configuration data (if you have set any) and ConfD status data from CDB. No data will be retrieved from the application in this example. All data is read from the ConfD Configuration DataBase (CDB).
Writing configuration, for example when you perform a NETCONF <SET> running this example, e.g. by typing
$ netconf-console cmd-set-dhcp-defaultLeaseTime-1h.xml
will trigger the example application since it registered as a subscriber for all configuration changes under the /dhcp path (see dhcpd.yang).
So, again, the data is set through a NETCONF <SET> transaction that writes the configuration data to the CDB running datastore. As part of the transaction when the data has been committed to CDB, ConfD will notify applications that are subscribing for this configuration update
Below a short summary on how the application registers as a subscriber and handle subscription notifications, taken from dhcpd_conf.c in the 1-2-3 example:
confd_init(); /* initialize the ConfD library */
socket(); /* create a new communication socket */
cdb_connect() /* connect the socket to ConfD for subscribing to configuration changes */
cdb_subscribe() /* register for subscribing to /dhcpd configuration changes */
cdb_subscribe_done() /* tell ConfD that we are ready to receive configuration change notifications */
... /* Now we start polling the socket for subscription update notifications */
cdb_read_subscription_socket() /* When the data arrive on the socket we read it to find out if we got an event matching our subscription */
socket(); /* create a new communication socket */
cdb_connect() /* connect the socket to ConfD for reading data */
cdb_start_session() /* start a session towards the ConfD CDB running configuration datastore */
cdb_set_namespace(() /* set the namespace of the data we want to read, here dhcpd */
cdb_get_* (), cdb_num_instances(), cdb_pushd(), cdb_popd(), cdb_exists() ... /* we read the configuration data from CDB running datastore */
cdb_close() /* we close the read CDB running config data socket */
cdb_sync_subscription_socket() /* We tell ConfD over the subscription socket that our subscriber is done reading the updated configuration */
/* Here we go back to polling for configuration updates */
Checkout $CONFD_DIR/examples.confd/cdb_subscription/iter_c for what is, for most application use-cases, the most effective way of reading subscription data after configuration change notifications.
Checkout $CONFD_DIR/examples.confd/intro/5-c_stats or 7-c_actions for intro examples on how the application can provide statistics and execute actions triggered by for example NETCONF <GET> and <ACTION> RPCs.
Also, don’t forget to checkout the README files that comes with the examples. They give you a good overview of what’s going on in the examples.