# Confd behaviour for stats display based on yang implementation?

**URL:** <https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856>\
**Category:** YANG\
**Created:** [November 25, 2016, 8:19am UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856 "2016-11-25T08:19:06Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kamal\_M](https://avatars.discourse-cdn.com/v4/letter/k/a88e4f/32.png) [@Kamal\_M](https://dmap-community.ductus.global/u/Kamal_M)\
**Post date:** [November 25, 2016, 8:19am UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/1 "2016-11-25T08:19:06Z")

</div>

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.

 ![](https://canada1.discourse-cdn.com/flex010/uploads/ductus_dmap/original/1X/15ee267a7dfebd6d177625a7aa33953a4dfd65a3.PNG)

Thanks,  
Kamal

---

<div class="post-metadata">

**Author:** ![mnovak](https://yyz2.discourse-cdn.com/flex010/user_avatar/dmap-community.ductus.global/mnovak/32/183_2.png) [@mnovak](https://dmap-community.ductus.global/u/mnovak)\
**Post date:** [November 25, 2016, 9:44am UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/2 "2016-11-25T09:44:10Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Kamal\_M](https://avatars.discourse-cdn.com/v4/letter/k/a88e4f/32.png) [@Kamal\_M](https://dmap-community.ductus.global/u/Kamal_M)\
**Post date:** [November 25, 2016, 9:57am UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/3 "2016-11-25T09:57:34Z")

</div>

Can I implement my process with get\_elem() alone ?

---

<div class="post-metadata">

**Author:** ![josephm](https://avatars.discourse-cdn.com/v4/letter/j/a88e57/32.png) [@josephm](https://dmap-community.ductus.global/u/josephm)\
**Post date:** [November 25, 2016, 10:06am UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/4 "2016-11-25T10:06:56Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![Kamal\_M](https://avatars.discourse-cdn.com/v4/letter/k/a88e4f/32.png) [@Kamal\_M](https://dmap-community.ductus.global/u/Kamal_M)\
**Post date:** [November 25, 2016, 10:09am UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/5 "2016-11-25T10:09:12Z")

</div>

**Here is my yang model:**

```auto
/* 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…**

---

<div class="post-metadata">

**Author:** ![josephm](https://avatars.discourse-cdn.com/v4/letter/j/a88e57/32.png) [@josephm](https://dmap-community.ductus.global/u/josephm)\
**Post date:** [November 25, 2016, 10:39am UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/6 "2016-11-25T10:39:29Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![Kamal\_M](https://avatars.discourse-cdn.com/v4/letter/k/a88e4f/32.png) [@Kamal\_M](https://dmap-community.ductus.global/u/Kamal_M)\
**Post date:** [November 25, 2016, 10:47am UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/7 "2016-11-25T10:47:28Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Kamal\_M](https://avatars.discourse-cdn.com/v4/letter/k/a88e4f/32.png) [@Kamal\_M](https://dmap-community.ductus.global/u/Kamal_M)\
**Post date:** [November 28, 2016, 9:45am UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/8 "2016-11-28T09:45:30Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Kamal\_M](https://avatars.discourse-cdn.com/v4/letter/k/a88e4f/32.png) [@Kamal\_M](https://dmap-community.ductus.global/u/Kamal_M)\
**Post date:** [November 28, 2016, 9:57am UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/9 "2016-11-28T09:57:31Z")

</div>

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,  
…

}

---

<div class="post-metadata">

**Author:** ![Kamal\_M](https://avatars.discourse-cdn.com/v4/letter/k/a88e4f/32.png) [@Kamal\_M](https://dmap-community.ductus.global/u/Kamal_M)\
**Post date:** [November 29, 2016, 5:54am UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/10 "2016-11-29T05:54:56Z")

</div>

Hi Team,

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

Thanks,  
Kamal

---

<div class="post-metadata">

**Author:** ![josephm](https://avatars.discourse-cdn.com/v4/letter/j/a88e57/32.png) [@josephm](https://dmap-community.ductus.global/u/josephm)\
**Post date:** [November 29, 2016, 1:13pm UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/11 "2016-11-29T13:13:33Z")

</div>

> 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.

---

<div class="post-metadata">

**Author:** ![Kamal\_M](https://avatars.discourse-cdn.com/v4/letter/k/a88e4f/32.png) [@Kamal\_M](https://dmap-community.ductus.global/u/Kamal_M)\
**Post date:** [November 29, 2016, 1:29pm UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/12 "2016-11-29T13:29:23Z")

</div>

**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)**

---

<div class="post-metadata">

**Author:** ![josephm](https://avatars.discourse-cdn.com/v4/letter/j/a88e57/32.png) [@josephm](https://dmap-community.ductus.global/u/josephm)\
**Post date:** [November 29, 2016, 1:50pm UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/13 "2016-11-29T13:50:40Z")

</div>

> 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.

---

<div class="post-metadata">

**Author:** ![Kamal\_M](https://avatars.discourse-cdn.com/v4/letter/k/a88e4f/32.png) [@Kamal\_M](https://dmap-community.ductus.global/u/Kamal_M)\
**Post date:** [November 29, 2016, 1:59pm UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/14 "2016-11-29T13:59:37Z")

</div>

**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

---

<div class="post-metadata">

**Author:** ![josephm](https://avatars.discourse-cdn.com/v4/letter/j/a88e57/32.png) [@josephm](https://dmap-community.ductus.global/u/josephm)\
**Post date:** [November 29, 2016, 2:56pm UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/15 "2016-11-29T14:56:52Z")

</div>

> [@Kamal\_M](#):
>
> get\_next error {external, “”} for callpoint ‘router-nbase-stats’ path /router-dcl:filter-views/vrf-lim-debug-stats/vrf

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

---

<div class="post-metadata">

**Author:** ![josephm](https://avatars.discourse-cdn.com/v4/letter/j/a88e57/32.png) [@josephm](https://dmap-community.ductus.global/u/josephm)\
**Post date:** [November 29, 2016, 5:13pm UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/16 "2016-11-29T17:13:14Z")

</div>

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"`

---

<div class="post-metadata">

**Author:** ![Kamal\_M](https://avatars.discourse-cdn.com/v4/letter/k/a88e4f/32.png) [@Kamal\_M](https://dmap-community.ductus.global/u/Kamal_M)\
**Post date:** [December 1, 2016, 9:13am UTC](https://dmap-community.ductus.global/t/confd-behaviour-for-stats-display-based-on-yang-implementation/856/17 "2016-12-01T09:13:05Z")

</div>

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