By default, the netconfd-pro server will use its own database, which is stored in an XML file.


It is also possible to use an external database instead of this built-in database. 

There are 2 ways this can be done:

  • yp-system: nvload and nvsave callbacks (for full database read and write)
  • DB-API and transaction-hook (for incremental database read and write)

Method 1: yp-system

This method uses the --startup CLI parameter.  The system is configured to use the startup config but this will get overridden in the initialization procedure. The external callbacks NV-Load and NV-Save will be used instead of the internal database for saving the configuration.

The yp-system library is used to integrate API callbacks that are not specific to a YANG module.

In the yp_system_init1 function, register your NV-Load and NV-Save callback functions.
There are examples in the example-system.c file installed in the /usr/share/yumapro/src/libsystem/src directory.
Refer to the example_nvsave and example_nvload functions.

Each time the server needs to load the non-volatile configuration it will call the NV-Load callback.
Each time the server needs to save the non-volatile configuration it will call the NV-Save callback.

Method 2: DB-API

This method uses the --no-startup CLI parameter.  The system is configured to skip the startup config.


A Transaction Complete callback or some type of SIL callback needs to be registered so edits from NETCONF or RESTCONF are saved in the external database. 


Saving edits to the external database:


This can be set up so most of the transaction model is ignored, and only commits to the running datastore are monitored.


The callback needs to contact its external database somehow and add the incremental change represented by the transaction in progress.


Loading edits from the external database:


The DB-API protocol is available that allows a separate process to send edits to the netconfd-pro main server. 

Refer to the db-api-app example for sample code for this purpose.  The DB-API service uses the YControl library to connect, reconnect, register, and communicate with the main server.

The DB-API process appears to the main server as a sub-system.

 

 Run db-api-app  (your process with adapted code)

     1) connect to main server

     2) send edits 1 at a time or the entire datastore at once

    status_t res = db_api_send_edit_ex(path_str,
                                       operation_str,
                                       value_str,
                                       patch_id_str,
                                       system_edit);
    

    3) send edits as needed when external config is updated