Difference between revisions of "Sweetcomb/Sysrepo"
m (→Sysrepo) |
m (→Sysrepo) |
||
Line 5: | Line 5: | ||
* '''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 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. | * '''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 == | == Writing a configuration callback == | ||
Line 37: | Line 33: | ||
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. | 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. It differentiates two kind of nodes: | ||
+ | |||
+ | * 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 == |
Revision as of 15:53, 25 March 2019
Contents
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. It differentiates two kind of nodes:
- 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