- To continue from this post, two common ways are for example to from your configuration change subscriber implement an
iter() callback that you register through cdb_diff_iterate() or you can call cdb_get_modifications()
For a cdb_diff_iterate() example see: $CONFD_DIR/examples.confd/cdb_subscription/iter_c/cdbl.c
From the ConfD confd_lib_cdb man page $CONFD_DIR/man/man3/confd_lib_cdb.3:
The cdb_diff_iterate() function can be used to iterate over the changes made in CDB data that matched the particular subscription point.
The user defined function iter() will be called for each element that has been modified and matches the subscription. The iter() callback receives the confd_hkeypath_t kp which uniquely identifies which node in the data tree that is affected, the operation, and optionally the values it has before and after the transaction. The op parameter gives the modification as MOP_CREATED, MOP_DELETED, MOP_MODIFIED, MOP_VALUE_SET, MOP_MOVED_AFTER.
For a cdb_get_modifications() example see this post
From the ConfD confd_lib_cdb man page $CONFD_DIR/man/man3/confd_lib_cdb.3:
When cdb_get_modifications() returns CONFD_OK, the results are in values, which is a tag value array with length nvalues.
The tag value array differs somewhat between how it is described in the confd_types(3) manual page, most notably only the values that were modified in this transaction are included. In addition to that these are the different values of the tags depending on what happened in the transaction:
• A leaf of type empty that has been deleted has the value of C_NOEXISTS, and when it is created it has the value C_XMLTAG.
• A leaf or a leaf-list that has been set to a new value (or its default value) is included with that new value. If the leaf or leaf-list is optional, then when it is deleted the value is C_NOEXISTS.
• Presence containers are included when they are created or when they have modifications below them (by the usual C_XMLBEGIN, C_XMLEND pair). If a presence container has been deleted its tag is included, but has the value C_NOEXISTS.
By default cdb_get_modifications() does not include list instances (created, deleted, or modified) - but if the CDB_GET_MODS_INCLUDE_LISTS flag is included in the flags parameter, list instances will be included. Created and modified instances are included wrapped in the C_XMLBEGIN / C_XMLEND pair, with the keys first. Deleted list instances instead begin with C_XMLBEGINDEL, then follows the keys, immediately followed by a C_XMLEND.
-
The ConfD transaction state machine:
+-------+
| START |
+-------+
|
|
v
+------+
------> | READ | --------------------> START
+------+
^ |
| |
| v
+----------+
------> | VALIDATE | -----------------> START
+----------+
|
|
v
+-------+
-------> | WRITE | -------------------> START
+-------+
|
|
v
+----------+ +-----------+
| PREPARED | -----------> | COMMITTED |
+----------+ +-----------+
| |
| |
v |
+---------+ v
| ABORTED | START
+---------+
|
|
v
START
You can register with ConfD to participate in different phases of the transaction. A few of the common ones are:
• Subscriber: An application using the CDBAPI that has requested to be notified when an operator modifies parts of the configuration that the application is interested in, e.g. set hostname or add an entry to the interface table. Called in the commit phase.
• Data Provider: An application that knows the current value of something in the data model. ConfD will contact this application through the DPAPI to get the current value when requested by an operator, e.g. show CPU temperature. Called in the read phase.
• Validator: An application that participates in the validation, i.e. determining if the configuration that results when applying a certain transaction is valid. A validator can respond “Yes, this is fine”, “No, this configuration is invalid because …” or “Warning: This configuration is valid, but are you aware that … (proceed/abort) ?” Validators use the MAAPI since they need to see the upcoming configuration the same way an operator sees it, not the configuration currently stored in the database. Called in the validation phase
• Two-phase subscriber: A subscriber application that is also participating in the prepare phase using the CDBAPI. It can thereby reject upcoming configuration changes.
• Transaction hook and set hook: An application that is invoked when an operator wants to commit a transaction, in the validation phase before the validation starts (transaction hook), or each time the operator in the write phase sets a value in a transaction (set hook). The application can then modify or extend the transaction with further modifications on behalf of the operator. These modifications are usually done in parts of the data model that are invisible to the operator. Hooks use the MAAPI since they are modifying transactions on behalf of the operator.