There are many ways to configure and build the server for storing and retrieving datastore contents.

  • Local internal database: configuration in memory and NV-storage in netconfd-owned XML file
  • Local internal database + NV-store hook: configuration in memory and NV-storage via callback functions, and transferred to/from the server as an XML file
  • Local internal database + no-NV-store: configuration in memory and NV-storage is managed by the yp-system and/or SIL code.  The server will not attempt to load or store the configuration to non-volatile storage
  • Local internal database + external edits: your external process communicates with the netconfd-pro process to initiate external edits (e.g., initiated from legacy CLI or internal database)


Local internal database



This is the default database configuration and provides complete management of all database storage and management.  No extra APIs or CLI parameters are required.


Configuration properties:

  • Tree-based data structures in memory for run-time transaction processing
  • This is the canonical database
  • There is no other database
  • The non-volatile load and store is done by netconfd-pro using the --startup filespec to store the configuration
  • The file is encoded as an XML instance document containing 1 element named 'data'
  • No YANG default leafs are stored in this file


Local internal database + NV-store hook




This database variant allows the vendor/system code to manage the non-volatile configuration. The system control is constrained to the replacement of the functions that load and store the configuration file.


This variant requires use of the NV-store APIs (described in the Database Operations section of the YumaPro Developer Manual).


Configuration properties:

  • Tree-based data structures in memory for run-time transaction processing
  • This is the canonical database
  • There is no other database
  • The non-volatile load and store is done by netconfd-pro via user callback functions.
  • The NV-store callback functions manage the actual non-volatile representation and storage.
  • The NV-Store callback transfers the configuration to/from netconfd-pro as an XML file
  • YANG default leafs will be treated as explicitly set if contained in the transfer file


Local internal database + no-NV-store



This variant allows either a simple deployment that does not support non-volatile storage of configuration or

a more flexible system-managed non-volatile storage design, using multiple server APIs.


This variant requires that the CLI parameter --no-nvstore is present.

The --startup CLI parameter is ignored if --no-nvstore is used.


Various initialization callback APIs and transaction APIs  can be used to load and save the non-volatile storage

Configuration properties:

  • Tree-based data structures in memory for run-time transaction processing
  • This is the canonical database
  • There is no other database
  • The non-volatile load and store is done by netconfd-pro via various user callback functions.
  • The internal NV-store and NV-store callback functions are not used
  • The yp-system library or individual SIL libraries can be used to initialize and fill the empty database with configuration and operational data nodes
  • Transaction hooks can be used to save the running configuration at run-time if any client edit transactions are processed by the server


Local internal database + External Edits e.g. Legacy CLI



This database variant allows an external process to initiate database edits, that are processed by the server as user or system edits.


The DB-API functions described in the next section can be used by the subsystem to edit the server configuration database.


This variant can be used with other variants for processing non-volatile storage. This variant is used to co-exist with a legacy or canonical database owned by the system.


Configuration properties:

  • Tree-based data structures in memory for run-time transaction processing
  • This may or may not be the canonical database, depending on the non-volatile storage options.
  • There may be another database in the system
  • The server uses its copy in memory as the complete database
  • The DB-API “send_edit” and “send_edit_ex” API functions can be used to transfer configuration from the system to netconfd-pro.
  • Data is transferred in XML
  • Error responses are sent by the server if an edit is not accepted.
  • An error will be returned if a client is already in the process of editing the database
  • The db-api-app application is installed in /usr/share/yumapro/src/db-api-app by default, and includes some examples of initializing the DB-API service and sending edits to the server


Startup Options


There are 3 startup parameter variants, using the YANG 'start' choice statement.


The --startup=filespec CLI parameter can be used to specify the NV-storage file. The default filespec is $HOME/.yumapro/startup-cfg.xml.


The --factory-startup parameter can be used to load an empty configuration instead of the stored configuration. If the default configuration is used (startup-cfg.xml) then it is reset to factory default values.


The --startup-factory-file parameter can be used to load an non-empty configuration instead of the stored configuration. This file is used instead of the default configuration (startup-cfg.xml). It is ignored unless --factory-startup is also used.


The --no-startup parameter can be used to load an empty configuration instead of the stored configuration. The default configuration (startup-cfg.xml) is not affected by this parameter.


To learn more about using DB-API please review the Solution Article "How do I use DB-API?"