If no callpoint defined, no exist_optional call is received from ConfD with external DB

Hi ,

We are integrated as External DB.
If the “presence” keyword is present in the yang for the sub-container without the callpoint definition. We have implemented the GET_Object and Get_Next_Object implementation.
We don’t receive the “exist_optional” call on the sub-container now. Is this expected ?

If we add the callpoint , we start getting the exist_optional call. Can you guide without callpoint definition we can get the exist_optional call.

When we manage device in NSO, we get error for the l2-transport-name is not configured,
In the return of the get_next_object call. if no value is not configured in the sub container it passes as .

Example :
Interfaces {
Interface {
leaf name; // key
transport {
presence;
use l2-transport-config
}
}
}

grouping l2-transport-config {

    leaf l2-transport-name{
        type entity-name;
        mandatory true;
            }
       ......
  }

Callpoint in annotation file :
tailf:annotate “/if:interfaces/if:interface/” {
tailf:callpoint Interface{}

From the confd_lib_dp man page under get_object()

Remember, the callback exists_optional() must always be implemented when we have presence containers or leafs of type empty. If we also choose to implement the get_object() callback, ConfD can sometimes derive the existence of such a node through a previous call to get_object(). This is however not always the case, thus even if we implement get_object(), we must also implement exists_optional()if we have such nodes.

Under confd_data_reply_value_array()

Thus, a container or a leaf of type empty must be passed as its equivalent XML tag if it exists. If a presence container or leaf of type empty does not exist, it must be passed as a value of C_NOEXISTS. If a presence container does not exist, its non-existing values must not be passed - it suffices to say that the container itself does not exist.

So if your get_next_object() callback using confd_data_reply_value_array() returns an “interface” list entry that includes the “transport” container, not a C_NOEXISTS, and not the mandatory “l2-transport-name”, that is indeed an error.

Thanks @cohult.
We have implemented exist_optional. but still I don’t see the callback call coming from CONFD.
Can you explain why ?

2nd part , I understood . I think we need take care of it.

The first part of the quote from the man page covers that. Note that where it says “get_object()” it should also say “get_next_object() and find_next_object()” for clarity.

If we also choose to implement the get_object() callback, ConfD can sometimes derive the existence of such a node through a previous call to get_object().

So a call to get_next_object() is sufficient for your example to figure out if the presence container is present or not. But then the data provider application likely did not return C_NOEXISTS where it should have.