Question on data callbacks find and get

General
1

Hi
In 6.3.9, for one of the CLIs, the find_next call back was triggered. Later I have upgraded to 7.3.2, but get_next() call back is getting triggered for the same CLI now instead of find_next() after the upgrade. Even though, I went though the release notes, I couldn’t figure out the reason for this specific change. Could you please help me to understand this behavior change?

Thanks
Susanth

2

As always, you should not assume and hardcode any particular order or a certain data provider callback to be called for some show show command. ConfD will select the data provider callback it believes fit best for the data to be read from the data provider application given the callbacks you have registered. That may change between releases, and especially for the CLI where ConfD besides reading data also has to calculate tab completes and showing tables.

Anyhow, there is no reason to register get_next() when you have registered find_next(). I would suggest you move your get_next() handling to find_next() and remove the get_next() callback from your implementation.

See the ConfD 7.5 examples.confd/dp/generic_perf if you are interested in what the optimal DP setup is for most use cases.

3

Hi,

Thank you very much for the suggestion. We are studying out old implementation for modifications to same effect.

We have one more question in the same.

container container1 {
list list1 {
key “leaf1 leaf2 leaf3”;
tailf:cli-no-key-completion;
tailf:cli-incomplete-show-path
{
tailf:cli-min-keys “2”;
}
tailf:callpoint cp
{
tailf:opaque ‘2:container1 list1:leaf1/string leaf2/string leaf3/uint16:0’;
}
leaf leaf1 {
type string;

        }
        leaf leaf2 {
           type string;
        }
        leaf leaf3 {
           type uint16;             
        }

}
For the above yang model. There is difference in find_next behaviour.
There are three keys in the model and we specify two keys to get entire list. It used to work in confd6.3.9.

In 6.3.9 confd version
TRACE CALL data find_next(thandle=53, container1/list1, same_or_next, {leaf1 leaf2}) --> CONFD_DELAYED_RESPONSE

In 7.3.2 confd version
TRACE CALL data find_next(thandle=53, container1/list1, next, {}) --> CONFD_DELAYED_RESPONSE

Could you please give your inputs how to gets keys from in find_next callback

Thanks
Susanth

4

Hi,

For the find_next() callback, if nkeys == 0 then ConfD is asking for the first list entry.
If your 6.3.9 based implementation did not cover that use case, it didn’t really work. Rather you were lucky.

Best regards

5 
    container  container1 {      
          list list1 {         
                key "leaf1 leaf2 leaf3";
                tailf:cli-no-key-completion;
                tailf:cli-incomplete-show-path
                {
                   tailf:cli-min-keys "2";
                }
                tailf:callpoint cp
                {              
                   tailf:opaque '2:container1 list1:leaf1/string leaf2/string leaf3/uint16:0';
                }
                leaf leaf1 {
                  type string;
                  
                }
                leaf leaf2 {
                   type string;
                }
                leaf leaf3 {
                   type uint16;             
                }           
    }

For the above yang model. There is differenc in find_next behaviour. 
There are three keys in the model and we specify two keys to get entire list. It used to work in confd6.3.9.

In 6.3.9 confd version 
TRACE CALL data find_next(thandle=53, container1/list1, same_or_next, {leaf1 leaf2}) --> CONFD_DELAYED_RESPONSE

In 7.3.2 confd version 
TRACE CALL data find_next(thandle=53, container1/list1, next, {}) --> CONFD_DELAYED_RESPONSE

Could you please give your inputs how to gets keys from in find_next callback
6

See above Question on data callbacks find and get