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.
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.
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…
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.
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.
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)?
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
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.
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"