Operational data list key not set in the keypath/cli

Hi Team,

I am trying to create a show command for a particular session where I take the address as the I/P from cli/user and display certain leafs for the same session. I have a list defined keyed at this address. However in the CLI, I am not able to pass any address. below is my yang and trace logs.

list session {
                key addr;
                tailf:info "session stats";
                max-elements 1;

                leaf addr {
                    type string;
                    description "session IP";

                leaf dpd-req {
                    type uint32;
                    description "Number of dpd requests";

                leaf dpd-resp {
                    type uint32;
                    description "Number of dpd response";


TRACE CALL data get_next(thandle=7, /tls-gateway/stats/session, -1)
 6-Dec-2016::08:39:07.342 98802/7f0b3d311700/10 SEND {28,2,0,false}

What I am looking for is to pass the address as /tls-gateway/stats/session/{addr}/addr

This looks pretty basic, but somehow this model is not reflecting in my CLI, am I missing anything?

Thanks in advance!


i’t not completely clear where do you try to pass the key value to…

I assume for following discussion that the model section you have pasted is “config false;”, and managed by a registered data provider callbacks…

You’ve pasted log excerpt from get_next() invocation. Passing the key value inside get_next() does not have a meaning in this specific case, as the get_next() implementation is designated to provide key values from “source” to user, not the other way around.

However, when you type command like: “show ... session”, this will lead to invocation of get_elem() callbacks with the keypath including your defined key value, e.g. “.../session{}/dpd_req

Of course this could be required if you have e.g. nested lists inside lists - first list to “get value form user”, the inner list to iterate something in backed using this input from user.

In addition to regular data provider implementation, you can e.g. disable the code-completion for key values in the CLI by adding a CLI-annotations to the “session” list if needed.

You can try adding these to your “sessions” list, to restrict user from running the “generic” query on list:


(see user guide for descriptions)

(though you still should have get_next() implementation that could iterate the key values from the source of operational data…)


Thanks for your reply!

Yes, this is a “config false” section and I have registered data provider callbacks(get_next and get _elem)
My problem here is to pass the IP “” from CLI which I am not able to. Here is the o/p when I try to pass the IP

singlebox# show tls-gateway stats session ?
Description: session stats
Possible completions:
  displaylevel   Depth to show
  |              Output modifiers

I am expecting the CLI to take the string input which I will process in the get_elem and get_next and return the stats for that particular session.

I am not able to pass this IP which is needed before I do any parsing.

I may have misunderstood your question - please clarify what do you mean by “passing” - from where, to where? On what specific moment?


I am referring to the CLI prompt for ConfD, where I enter “singlebox# show tls-gateway stats session ?”

I want to pass an address after the session keyword. The cli is not letting me configure the same.

This is most probably caused by the fact, that your implementation of get_next() callback responds with “no keys” to ConfD. (e.g. via “confd_data_reply_next_key(tctx, NULL, -1, -1);”).

CLI then does not give any “options” as a hint in command being typed - it expects that there is nothing inside the list that needs to be displayed…

You should still be able to type in the value of key and execute command despite this fact.
(it works for me when i run e.g. ConfD example from intro/5-c_stats with hacked get_next() to return no keys in any invocation)


This is exactly what I am doing, but when I go ahead and execute the command it cribs with the below error

 singlebox# show tls-gateway stats session
 syntax error: unknown element

Why is this an unknown element, it anyways calls the get_elem callback with the complete keypath which I want.

What I am trying to achieve here is to take this IP and display stats particular to this IP only. There is no next key/IP here. Is there any other data type than “list” which can be used here?

You need working get_next() implementation for the model to work correctly.
This is due to definition of the specific callbacks, their return values, and implied behavior… (if no key exists in list according to get_next() == no questions asked about list contents).

Depending on how much info you need to be displayed, you can try looking into action as a workaround. Please see ConfD user guide, “Chapter 11. Actions”.
Here, you can theoretically use input parameter of action as the “filter” you need, and the output parameters of action as the expected output…

regarding the “syntax error: unknown element” - i’m not able to reproduce
This can be caused by e.g. yang model difference we have, different ConfD version etc.

My CLI commands attempted:

mlinux# show arpentries arpe ?
Possible completions:
  |  <cr>
mlinux# show arpentries arpe
IP       DATA
---------------------  somestring


As shown above, i am able to run “successful” command that in my understanding corresponds to your needed use case (except for the missing key suggestions):

TRACE CALL data get_next(thandle=7, /arpentries/arpe, -1) --> CONFD_OK

here, i return -1 “incorrectly” in the get_next() implementation…
As next steps, i see invocation of:

TRACE CALL data get_elem(thandle=7,/arpentries/arpe{}/ip) (  --> CONFD_OK
TRACE CALL data get_elem(thandle=7,/arpentries/arpe{}/ip) (  --> CONFD_OK
TRACE CALL data get_elem(thandle=7,/arpentries/arpe{}/ip) (  --> CONFD_OK
TRACE CALL data get_elem(thandle=7,/arpentries/arpe{}/ip) (  --> CONFD_OK
TRACE CALL data get_elem(thandle=7,/arpentries/arpe{}/data) ("somestring")  --> CONFD_OK

And finally, my model i tested with:

container arpentries {
  config false;
  tailf:callpoint arpe;
  list arpe {
    key "ip";
    leaf ip { type inet:ip-address; }
    leaf data { type string; }