Revision as of 09:40, 26 March 2019

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

Parsing XPATH