Issues with the new API for leaf-lists

Hi all,

I’ve upgraded from ConfD 6.4 to ConfD 6.6 and I’m trying to adapt my program to use the new API for leaf-lists. Everything went smoothly except for the two problems below:

1 - When using cdb_trigger_subscriptions(), libconfd processes the received configuration changes using the old API for leaf-lists. In other words, the cdb_diff_iterate() iterator is called with the operation parameter set to MOP_VALUE_SET and newv->type set to C_LIST. Wouldn’t it be possible to use the new leaf-list API to process changes triggered by cdb_trigger_subscriptions() in addition to run-time configuration changes?

2 - The man page of the confd_xpath_pp_kpath() function says the following:

Similar to confd_pp_kpath() except that the path is formatted as an XPath path, i.e. “/servers:servers/server[name=“www”]/ip” (…)

The problem is that I’m getting XPaths like this in my program: /frr-ripd:ripd/instance/static-route[10.0.2.0/24]

I’m not entirely sure, but I believe this notation is not a valid XPath expression (it’s not understood by the libyang library for instance). What I would expect is to have the leaf-list values formatted like this: /frr-ripd:ripd/instance/static-route[.="10.0.2.0/24"]. Does that make any sense? I’ve workarounded this problem using some obscure string manipulation in my program, but it would be nice if can remove this workaround somehow.

Any help would be appreciated.

Regards,
Renato.

Both your issues are clearly bugs in ConfD, and your expectation for the leaf-list-as-xpath is right on target - you can see an example in RFC 6020. If you have a support contract for ConfD, please open tickets for them to make sure they are tracked.

It’s possible to avoid “obscure” string manipulation in a workaround for the XPath issue by basically using confd_xpath_pp_kpath_len() to print all but the “last” element (the leaf-list element value), and then appending [.=", the result of calling confd_val2str() for the last element, and finally ]. The details make it pretty complex though, so perhaps obscure string manipulation ends up being simpler…