Confd behaviour for stats display based on yang implementation?

Hi Team,

Please help with this:

I have written a yang for my stats display(attached YANG file)
My command is “show nbase statistics vrf <vrf_name>”
I have to implement a process which upon request provides stats values to confd to display.
When I apply above command I would like to know how confd reacts for values(get_elem, get_next …), based on that I am planning to proceed further.

Thanks,
Kamal

Hello, I suggest you look at chapter 6.6 and 6.7 of ConfD user guide.
You can also look at confd_lib)dp man page (or in ConfD User Guide) and read description of data provider callbacks in:

struct confd_data_cbs

Generally, you should implement get_elem and get_next callbacks and then you can add
get_object, get_next_object, find_next, … for performance optimization, if needed.

Can I implement my process with get_elem() alone ?

Hello,

we cannot see the attached yang file - not sure how the model looks.

In general, which callbacks are invoked by ConfD is defined “internally” in the ConfD processes, and depends on both yang model structure, and which callpoint callbacks are registered/missing.

General recommendations and use-cases of the specific callbacks are described in the user guide sections that Michal recommended above.

E.g. if you don’t have any lists in the yang model, get_elem() could be sufficient without any other callbacks…
When you have lists in the data model, then get_next() is needed, or the get_next_object() - to allow iteration of the keys of the list… (get_elem() cannot do that), etc…

Here is my yang model:

/* Nbase statistics show module */
module router-nbase-newscope {
    // imports, namespaces, etc...

   /*NBase Statitics Show commands */
    augment /router-dcl:filter-views {
        container vrf-lim-debug-stats{
                config false;
                tailf:callpoint router-nbase-stats;
                list vrf {
                        key vrf-name;
                        leaf vrf-name {
                                type string {
                                        length "1..64";
                                }
                                tailf:info "<vrf-name> vrf name for displaying the details";
                        }
                        leaf intf_add_success{
                                type uint32;
                        }
                        // ... other leaf elements here...
              }
      }
   }
}

edited by josephm - shortened yang module to show only imporant structure…

looking into model, as i stated in my response shortly above, you will need not only get_elem(), but also one of the “next” callbacks because of the list vrf in your model.

either get_next() - it should be bit more easy than the more complex - get_next_object() (which is, on the other hand, more performance enhancing in some cases…).

Of course, if you implement both, you will have even better coverage for good performance - next_object() being called by confd when all data is displayed, next() when only keys are needed for some reason…

The above explanation satisfied my requirement.
I will look into chapter 6.6 and 6.7 of ConfD user guide as mentioned above.
Would like to continue this thread if I get more doubts.

Thanks,
Kamal

I have implemented my application using get_elem() & get_next().
When I apply :show nbase statistics vrf vrf_name" all the values are displayed on terminal.

But, from the logs I can see get_next() not invoked at all.

From the cli when I provide a vrf name that doesn’t exist then I am validating this and calling confd_data_reply_not_found(tctx) followed by return CONFD_OK, on the terminal I can see some undefined output & from the logs I can see get_next() invoked by confd.

I am not sure what is happening. Please clarify this.

struct confd_data_cbs nbase_ldp_statistics_cbs = {
.callpoint = router_nbase_newscope__callpointid_router_nbase_stats,
.get_elem = router_nbase_stats_get_elem,
.get_next = router_nbase_stats_get_next
};

int register_providers(struct confd_daemon_ctx *dctx)
{

&nbase_ldp_statistics_cbs,

}

Hi Team,

What could be the solution for above problem ?
Kindly help solving this error.

Thanks,
Kamal

I have implemented my application using get_elem() & get_next().
When I apply :show nbase statistics vrf vrf_name" all the values are displayed on terminal.
But, from the logs I can see get_next() not invoked at all.

that is probably expected - get_next() invocation is not necessary when showing data from specific table list entry

From the cli when I provide a vrf name that doesn’t exist then I am validating this and calling confd_data_reply_not_found(tctx) followed by return CONFD_OK, on the terminal I can see some undefined output & from the logs I can see get_next() invoked by ConfD.

This can be caused by various reasons - I’m not sure what do you mean by undefined output - this can be caused by other calls to leaf elements returned with non-terminated strings or binary data, etc.
When displaying model, there can be many subsequent calls to data provider - so without logs and reproduction scenario it’s hard to give further tips on which specifically provided “wrong” data…
(are there e.g. any messages in ConfD’s devel.log)?

This may need raising issue with ConfD support.

Please find info requested:

pl-ipfe-1_3_0# show nbase statistics vrf testtest
Error: application communication failure

System message at 2016-11-29 08:25:16...
    Subsystem stopped: nbase-confd-thread
pl-ipfe-1_3_0# Maximum number of reconnects reached, Tecla (nbase-stub) will exit!
pl-ipfe-1_3_0# pl-ipfe-1_3_0# 
System message at 2016-11-29 08:25:20...
Commit performed by system via tcp using system.
pl-ipfe-1_3_0# low level NBASE daemon has reconnected!pl-ipfe-1_3_0# 
System message at 2016-11-29 08:25:20...
    Subsystem started: nbase-confd-thread
pl-ipfe-1_3_0# 

[root@pl-ipfe-1_3_0 log]# tail -f devel.log
<ERR> 29-Nov-2016::08:25:15.987 pl-ipfe-1_3_0 confd[3888]: devel-c get_next error {external, ""} for callpoint 'router-nbase-stats' path /router-dcl:filter-views/vrf-lim-debug-stats/vrf
<ERR> 29-Nov-2016::08:25:15.988 pl-ipfe-1_3_0 confd[3888]: devel-c action command() error {external, ""} for callpoint show_nbase_statistics
<ERR> 29-Nov-2016::08:25:16.001 pl-ipfe-1_3_0 confd[3888]: confd external error when executing action application communication failure

(edited by josephm - formatted the console text)

Error: application communication failure
System message at 2016-11-29 08:25:16…
Subsystem stopped: nbase-confd-thread

This suggests there’s some error in the application - and detailed debugging is out of scope of this forum (application logs / source code needed, investigating the reason of app termination…).

If needed, please raise an issue via your support channel or create a more specific question in new discuss forum ticket.

Any comments on this:

[root@pl-ipfe-1_3_0 log]# tail -f devel.log
29-Nov-2016::08:25:15.987 pl-ipfe-1_3_0 confd[3888]: devel-c get_next error {external, “”} for callpoint ‘router-nbase-stats’ path /router-dcl:filter-views/vrf-lim-debug-stats/vrf
29-Nov-2016::08:25:15.988 pl-ipfe-1_3_0 confd[3888]: devel-c action command() error {external, “”} for callpoint show_nbase_statistics
29-Nov-2016::08:25:16.001 pl-ipfe-1_3_0 confd[3888]: confd external error when executing action application communication failure

as the error message states - it looks like something went “wrong” in the registered callbacks and/or other parts of the process executed in the callback implementation - but without the actual app (source/logs) we cannot debug what specifically

One extra thing that you can try is enabling the ConfD error log in confd.conf/dynamic configuration model (depending on what you use) - <errorLog> in <logs>, and see if it gets some info after error is printed in cli…

In shell, you can try printing contents of binary error log using confd command - "confd --printlog FILENAME"

The issue has been solved. Thank you guys for your valuable support. :slight_smile: