ConfD User Community

New set value of maapi_diff_iterate



As part of the validation check, we use maapi_diff_iterate in order to see all the leaves that were changed.
Is there a way to see the new value of each leaf?

I am looking for something similar to what we get in the configuration transaction - for each set/create/… we get the new values.

One more question - can we send additional parameters to the iter function in some way? we work with external DB and when we have keypath to be set and the new value we should call the external DB API. can we do it with this iter function?




the signature of iter function for maapi_diff_iterate is following:

enum maapi_iter_ret (*iter)(confd_hkeypath_t *kp, 
                                            enum maapi_iter_op op,
                                            confd_value_t *oldv,  
                                            confd_value_t *newv, 
                                             void *state)

in op parameter you get operation (MOP_CREATED, MOP_DELETED, …) and in newv parameter
you get new value (oldv is always NULL for maapi_diff_iterate).
Additional parameter can be passed through state (user supplied pointer).

See ConfD User Guide - confd_maapi.


thank you for the quick response.

how can the iter function return CONFD_ERR?
I see in the manual that ITER_STOP cause CONFD_OK.
If, for some reason, one of the validation fails, we would like to stop validation and return error.
How can it be done?




you can use void *state (or some global variable - not recommended) to inform caller of maapi_diff_iterate that there was some error.

In case of error, the iter function can:

set error flag in state

Then caller of maapi_diff_iterate should:

check if there is an error flag in state
if yes, then call maapi_diff_iterate_resume(s, ITER_STOP, NULL, NULL) to clean up the state and handle error

See ConfD User Guide - description of maapi_diff_iterate and maapi_diff_iterate_resume.



We use in the configuration transaction the flag CONFD_DAEMON_FLAG_STRINGSONLY.
we use the same deamon for the validation and the configuration transactions. for some reason we get the validation values as the “real” value (boolean/ip/…) and not as strings.
Is there a way to receive also all the validation’s values as string as well?



The validate() callback invoked for your data provider daemon should have the value (“newval”) in string form. If you read additional data via the MAAPI API, it is not affected by the CONFD_DAEMON_XXX flags, which pertain only to the data provider API - and there is no corresponding flag for the MAAPI API. But if your program loads schema information, it can use the confd_val2str() function to convert the values to strings.



I set validation point at my YANG module.
I configured neighbor and did commit-check.
The maapi_diff_iterate sent modify operation with keypath that isn’t under my validation point.
For example:
I put validation point at:
tailf:annotate “/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/eci-bgp:bgp/eci-bgp:neighbors” {
tailf:validate vpBgpNeighbors

and I configured: routing control-plane-protocols control-plane-protocol bgp master bgp neighbors neighbor peer-group ibgp

I got:
Op= modify Path= /routing/control-plane-protocols/control-plane-protocol{eci-bgp:bgp master}

Can you please help me to understand why?





Kindly reminder.
please assist. If the question isn’t clear or you need additional information please let me know.




As documented in confd_lib_maapi(3), maapi_diff_iterate() iterates “through the transaction diff”. If you want to iterate through a subset of the “transaction diff”, you can use maapi_keypath_diff_iterate(). There is no function corresponding to cdb_diff_terate() which only iterates through the subtree of a subscription point - one reason for this is that a validation callback will typically need to consider data outside of the subtree defined by a validation point. A perhaps more important question is why you are doing diff iteration at all in a validation callback. As explained in the “Semantic Validation” chapter of the User Guide, validation should make sure that the new configuration is valid - the changes that led to this new configuration should not be considered.



We changed it from maapi_diff_iterate to maapi_keypath_diff_iterate as you suggested. But doing that, the method iter() was not issued anymore.
can you suggest what should be done?


Not based on the information you provide, no. Presumably there were no changes in the subtree defined by the path you passed to maapi_keypath_diff_iterate(). You can see it in action in the validate/c_dependency example - whenever you modify anything in the /container/x list, the application will run maapi_keypath_diff_iterate() for each modified list entry (plus once for the /foo container - which obviously never has any changes).