Sysrepo itself supports 2 kinds of plugins not to be confused with sysrepo-plugind plugins. Datastore plugins define a set of callbacks that implement all the operations performed on a datastore allowing to implement a completely custom datastore. Every datastore for every YANG module can use a different datastore implementation. Notification plugins is the exact same concept used for implementing storage of notifications stored for replay.

There are 2 main reasons for implementing a custom datastore plugin. Firstly, it is almost a necessity when adding Sysrepo support for an existing application/daemon with its own configuration. Normally, the configuration would have to be stored both in the app configuration and a Sysrepo datastore, which has severe disadvantages. Not only is the configuration stored twice but keeping both configurations consistent is next to impossible, which then causes problems if different data are stored in each configuration. Datastore plugin essentially allows to hook the app configuration directly into Sysrepo so all the Sysrepo datastore operations such as load or store will be performed using the app configuration.

Secondly, the performance. The default datastore implementation is using libyang JSON files that are completely generic and can store any YANG data but some operations may take much longer than necessary and even require more space than a specialized datastore would. The main disadvantage of JSON files in terms of efficiency is performing small changes on large data. In this case the whole data must be parsed, the change performed, and the whole updated data written back. Instead, another datastore may be able to store the change directly without parsing and printing all the other stored data. As for the space required, if implementing a datastore for a specific YANG module, the data structure can fully depend on the schema nodes defined in the module and hence avoid storing any redundant information. Finally, note that the internal JSON datastore is also implemented as a datastore plugin so it can be used as an example implementation.

Notification Plugin API

MONGO DS plugin

MONGO DS plugin works as a database client. It connects and sends necessary commands directly to the MongoDB database server. It connects via the libmongoc library API and uses its functions to further communicate with the server. In MongoDB database there is a hierarchy of data. All data are stored in records which are then stored in collections which are then stored in databases. Each datastore for which MONGO DS plugin was deployed has its own database. The name of the database consists of a sr_ prefix and the name of the datastore, e.g. sr_factory-default. Data of each particular YANG module are then stored in a collection within the particular database. In order to avoid data conflicts the databases with the names sr_startup, sr_running, sr_candidate, sr_operational and sr_factory-default can only be used by the sysrepo library.

In order for the authentication (see README) to work the configured user has to have a read and a write permission on following databases: sr_startup, sr_running, sr_candidate, sr_operational and sr_factory-default.

REDIS DS plugin

REDIS DS plugin first connects to the Redis Stack database server via hiredis library API and then sends commands to the server using its functions. In Redis database all data are stored together. In order to differentiate between them, the keys have to be prefixed. The prefix for all sysrepo data is sr: and in order to avoid data conflicts the keys and indexes starting with a sr: prefix can only be used by the sysrepo library.

In Redis database there are certain limits with respect to data management which cannot be set to unlimited. The maximum amount of data which can be loaded from the database at once is set to one trillion. Some of these limits are enforced via the server configuration and since the sysrepo library does not have an access to the server's configuration file, it sets these limits via commands (more specifically the options MAXAGGREGATERESULTS and MAXEXPANSIONS).

In order for the authentication (see README) to work the user has to have the right to operate on all keys and indexes with the prefix sr: and at least the right to use these following commands: AUTH, FT.CONFIG SET, FT.AGGREGATE, FT.CURSOR READ, FT.CREATE, FT.DROPINDEX, HSET, HGET, SET, GET, DEL, COPY. Redis supports categories of commands, so to enable all of these commands at once you only have to enable a category containing all of them, e.g. @all.