Unable to Implement get_next() for leaf-list in nested list for confd version 6.7.4 for callpoints

CDB and CDB API
1

Hi,

I am trying to implement a callpoint in confd version 6.7.4. As per my understanding, implementation for leaf-list has changed as compared to the previous confd versions (6.4).
So I tried implementing leaf-list inside a list (arpe) in 5c-stats example and that is working fine. But I am not able get the keypath for leaf-list in case it is defined inside a multiple nested list in yang.

Yang Model:

  grouping _test_data {
    list company {
      leaf name {
        type string;
        mandatory true;
      }
      leaf-list task{
          type string;
      }
    }
  }

  container arpentries {
    config false;
    tailf:callpoint arpe;
    list arpe {
      key "ip ifname";
      max-elements 1024;
      leaf ip {
        type inet:ip-address;
      }
      leaf ifname {
        type string;
      }
      leaf hwaddr {
        type string;
        mandatory true;
      }
      leaf permanent {
        type boolean;
        mandatory true;
      }
      leaf published {
        type boolean;
        mandatory true;
      }
      uses _test_data;
    }
  }
}

My question is:

  1. Does confd support leaf-list get_next() implementation inside a nested list?
  2. If yes, How to handle it for callpoint?

Thankyou

2

ConfD definitely does support leaf-lists nested in lists, and get_next for leaf-lists behaves exactly as for lists. I suspect you got confused by that your list company has no keys (note that this is possible only because it represents operational data). It should not affect the leaf-list behavior, but the keypath may look a bit different - is this the problem?

3

This example represents the operational data. So I assume I need not to provide the key in the list. In the get_next() implementation of the nested list company I filled the leaf (name) value using confd_data_reply_next_key(). Then there was no subsequent call to the get_next() for leaf-list (task). My query is am I using the right API for the confd reply in case of get_next().

4

Yes, you are using the right API - as I wrote, expected get_next behavior for leaf-lists is exactly the same as for a corresponding list with one key and no other leaves.

I still think the problem is in the key-less list - you still need to handle get_next for such list and provide keys. There is a chapter dedicated to such lists in the user guide (look for Operational data without keys) and a C example, intro/8-c_stats_no_key.

Also, if something does not work as you expect, check log files, devel.log in particular; you may also want to increase log level in confd.conf.