ConfD User Community

CLI tab completion not work in list configurations with multiple keys

Hi,

CLI tab completion not work in some list with multiple keys.
If the list is not marked as ordered-by user in the YANG data model, the tab completion not work with the second key.

The callbacks are triggered in different ways for ordered-by user list an no ordered-by user list:

No ordered-by user list callbacks:

TRACE CALL data get_next(thandle=35, /tab-completion/plmn, -1)
–> CONFD_OK
TRACE CALL data get_next(thandle=35, /tab-completion/plmn, 0)
–> CONFD_OK
TRACE CALL data get_next(thandle=35, /tab-completion/plmn, -1)
–> CONFD_OK
TRACE CALL data get_next(thandle=35, /tab-completion/plmn, 0)
–> CONFD_OK
TRACE CALL data get_elem(thandle=35,/tab-completion/plmn{400 “”}/mcc)
(NOEXISTS) --> CONFD_OK
TRACE CALL data find_next_object(thandle=35, /tab-completion/plmn, same_or_next, {400})
–> CONFD_OK

ordered-by user list callbacks:

TRACE CALL data get_next(thandle=35, /plmn, -1)
–> CONFD_OK
TRACE CALL data get_next(thandle=35, /plmn, 0)
–> CONFD_OK
TRACE CALL data get_next(thandle=35, /plmn, -1)
–> CONFD_OK
TRACE CALL data get_next(thandle=35, /plmn, 0)
–> CONFD_OK
TRACE CALL data get_elem(thandle=35,/plmn{400 “”}/mcc)
(NOEXISTS) --> CONFD_OK
TRACE CALL data get_next(thandle=35, /plmn, -1)
–> CONFD_OK
TRACE CALL data get_next(thandle=35, /plmn, 0)
–> CONFD_OK

Is this a bug in ConfD? How to make tab completion work on not ordered-by user list with multiple keys?

Thanks!

Hi,

Could you tell if the ConfD triggered callbacks are correct? Or do you need more information on this?

Thanks!

I don’t see any buggy behavior on ConfD side - it is common that ConfD iterates over list instances several times, especially when CLI interaction is in play. But I see something that looks like a bug in your data provider, you posted this:

 TRACE CALL data get_elem(thandle=35,/plmn{400 “”}/mcc)
(NOEXISTS) --> CONFD_OK

This is most likely incorrect, the instance /plmn{400 ""} was presumably retrieved in one of the previous get_next invocations and mcc is the list’s first key. ConfD uses this kind of callback to verify list instance and your data provider needs to reply with the key value (if the instance indeed exists). See also here.

Do you think the kp "/plmn{400 “”}/mcc is correct in get_elem callback?
This callback is triggered by press tab in below CLI command:
user1@test#show running-config tab-completion plmn 400 <tab>

I think it it correct. Is mcc the first key of the list plmn? If so, then it is the instance existence check, as I wrote, and your application needs to handle it correctly; more severe problems than just malfunctioning tab-completion can be expected otherwise.

Yes, mcc is the first key of list plmn.

How to reply the instance existence check callback? Reply all the instances with first key matching with 400?
Because there is no such instance mapping with kp /plmn{400 “”}/mcc. When press tab, we expect to get the prompt on second key, as below:

user1@test#show running-config tab-completion plmn 400
Possible match completions:
name
Possible completions:
1 |

yang model:

container tab-completion {
list plmn {
    key "mcc mnc";
    leaf mcc {
        type string;
    }
    leaf mnc {
        type string;
    }
    leaf name {
        type string;
    }
}
}

instances:

{
“tab-completion”: {
“plmn”: [
{
“mcc”: 400,
“mnc”: 1,
“name”: “O2”
}
]
}
}

I see. So what is going on that when you press TAB after "plmn 400 " ConfD first checks whether there is an instance with mcc="400" and mnc="". Your data provider responded with NOEXISTS (which is actually correct, I was wrong before), and ConfD now needs to find possible values for mnc.

In case of a user-ordered list, there is not much else it can do than to run get_next over the list. In case of a system-ordered list, however, ConfD can speed that up by using find_next or find_next_object, if those callbacks are registered. Your data provider appears to register find_next_object, so ConfD calls it.

Your find_next_object() callback seems to be broken. See your application libconfd trace log.

Thanks for clarify how callbacks work in this scenario!

We can focus on our implementation of the find_next_object() callback now.