Sweetcomb/Sysrepo

Sysrepo

In Sweetcomb, there are two types of sysrepo callbacks we are really interested in:

• callbacks for operational data/State callback : In sweetcomb, they are registered with method GETITEM and sysrepo register them with sr_dp_get_items_subscribe(). These are the callbacks triggered by a NETFCONF get RPC with Netopeer2.
• callbacks for configuration data : In sweetcomb, they are registered with method XPATH and sysrepo register them with sr_subtree_change_subscribe(). These are the callbacks triggered by a NETCONF edit-config RPC with Netopeer2.

Writing a configuration callback

Events

A configuration callback is usually called twice for a single edit-config RPC. First, with SR_EV_VERIFY event and then with SR_EV_APPLY event.

• SR_EV_VERIFY : As it is the only phase which can return an error, in Sweetcomb, this is where VPP configuration happens.
• SR_EV_APPLY : Nothing is done for a SR_EV_APPLY in sweetcomb.

NB: errors are reported to the user with sr_set_error and SR_ERR_* return code.

Operations

A configuration callback contains a list of all changes required for one RPC

• SR_OP_CREATED:
• SR_OP_MODIFIED:
• SR_OP_DELETED:

Writing a state callback

It is the job of the developper to build every XPATH which will be replied to the client. Every reply comes as a pair (xpath, value).

XPATH replied is built with : sr_val_build_xpath() The value which goes whith XPATH is built with sr_val_t array.

The argument sr_val_t **values and size_t *values_cnt of the callback must be filled respectively with value array and the number of replies.

XPATH representation

Sysrepo sees XPATHs as a tree of nodes. As detailed in RFC6020, it differentiates two kind of nodes as :

• Configuration nodes : no config false in YANG model
• State nodes : config false in YANG model

For a given child node (configNode2 or stateNode2), all config parent nodes must exist (i.e. must have been configured):

• configNode0---->configNode1----->configNode2 //configNode0 and configNode1 must exist to access configNode2
• configNode0---->configNode1----->stateNode2 //configNode0 and configNode1 must exist to access stateNode2

On the contrary, stateNode can exist or not exist:

stateNode0---->stateNode1----->stateNode2 // /stateNode0/stateNode1/stateNode2 can be accessed

Source: https://github.com/sysrepo/sysrepo/issues/1224

Problem: This typically causes a problem for openconfig-interfaces YANG model. You have /openconfig-interfaces:interfaces/interface[name="myiface"]/state which should collect operational data but it cannot be called unless configuration interface "myface" exists in YANG running datastore i.e. it has been configured ...

Maybe, all interfaces should be present at startup in of running datastore ?