List update/insert is behaving incorrectly

General
1

in the below yang model , have a list entry with a integer key named sequence.
when i add a entry with key as 155 ,it adds.
when i add a entry wit key as 15 ,it updates the 155 key record.
similarly when i add a entry wiht key as 1, it again updates the 155 key record.

what could be the issue. the list key is highlighted in bold.

YANG model

grouping router-prefix-list-config {
    list prefix-list {
      description "Prefix list instance";
      key "type name";

      leaf type {
        description "Prefix list type";
        type prefix-list-type;
      }

      leaf name {
        description "Prefix list name";
        type string {
          length 1..64;
        }
      }

      list entry {
        description "Prefix list entry";

        key "sequence";

        leaf sequence {
          description "Prefix list sequence value";
          type uint32 {
            range "1..4294967295";
          }
        }

        leaf action {
...........................

CLI Queries

admin@config-service-0 06:08:45> show table MEDFunction router-cfg
prefix-list ipv4 Test-v4 {
    entry 155 {
        action                             deny;
        ipv4-prefix                        10.10.10.0/25;
        ipv4-prefix-length-lesser-or-equal 30;
    }
}
[ok][2022-12-05 06:08:47]
admin@config-service-0 06:08:47> configure
Entering configuration mode private
[ok][2022-12-05 06:08:51]

[edit]
admin@config-service-0 06:08:51% set MEDFunction router-cfg prefix-list ipv4 Test-v4 entry **15** ipv4-prefix 10.10.10.0/23 ipv4-prefix-length-lesser-or-equal 30 action deny
[ok][2022-12-05 06:09:21]

[edit]
admin@config-service-0 06:09:21% commit
Commit complete.
[ok][2022-12-05 06:09:26]

[edit]
admin@config-service-0 06:09:26% set MEDFunction router-cfg prefix-list ipv4 Test-v4 entry **1** ipv4-prefix 10.10.10.0/25 ipv4-prefix-length-lesser-or-equal 30 action den

[edit]
admin@config-service-0 06:09:34% exit
[ok][2022-12-05 06:09:38]
admin@config-service-0 06:09:38> show table MEDFunction router-cfg
prefix-list ipv4 Test-v4 {
    entry 155 {
        action                             deny;
        ipv4-prefix                        10.10.10.0/23;
        ipv4-prefix-length-lesser-or-equal 30;
    }
}
[ok][2022-12-05 06:09:42]
admin@config-service-0 06:09:42> configure
Entering configuration mode private
[ok][2022-12-05 06:09:48]

[edit]
admin@config-service-0 06:09:48% set MEDFunction router-cfg prefix-list ipv4 Test-v4 entry 1 ipv4-prefix 10.10.10.0/24 ipv4-prefix-length-lesser-or-equal 30 action deny
[ok][2022-12-05 06:10:13]

[edit]
admin@config-service-0 06:10:13% commit
Commit complete.
[ok][2022-12-05 06:10:17]

[edit]
admin@config-service-0 06:10:17% exit                                                                                                                    [ok][2022-12-05 06:10:30]
admin@config-service-0 06:10:30> show table MEDFunction router-cfg
prefix-list ipv4 Test-v4 {
    entry 155 {
        action                             deny;
        ipv4-prefix                        10.10.10.0/24;
        ipv4-prefix-length-lesser-or-equal 30;
    }
}
[ok][2022-12-05 06:10:33]
admin@config-service-0 06:10:33>
2

@cohult could you please help me on this?

3

There must be involved something more than what you posted here. The data model is quite simple and it alone behaves as one would expect - if you write entry 155, ConfD lets you configure that entry, if you write entry 1, ConfD lets you configure a new one. I would suspect that some your custom code is modifying what you write; possibly a custom completion code, or maybe a hook that changes the configuration? In such cases you should see entries like

<DEBUG> ....: devel-c new_action request daemon id: 0 usid: 14
<DEBUG> ....: devel-c new_action succeeded daemon id: 0 session id: -24 worker id: 4
<DEBUG> ....: devel-c action completion() request for callpoint 'cust-complete'
<DEBUG> ....: devel-c action completion() succeeded for callpoint 'cust-complete'

in your devel.log file, if you set /confdConfig/logs/developerLogLevel to trace in your confd.conf.

4

@mvf we don’t have any custom code/callback etc . same thing is working correctly via netconf xml push. its a issue only via CLI.
Even i tried it with a fresh confd 7.1 . still the issue is there with cli

5

ConfD 7.1 was released in April 2019. Have you tested with a ConfD version from 2022?

6

@cohult ,I have tried the same thing in confd 8.0.6 as well still its having this issue.
in my list i have a entry against a key test12345. when i tried adding an entry for the key test1234, it updated the values for the existing key test12345 instead of creating new one.
This issue is only observed in the cli operation. whereas netconf is working fine. is this a bug with cli? is there any way to control this behaviour

please find the attached yang model and cli screenshot

yang-model
yang-model564×626 11 KB

confd-cli-list-update-issue
confd-cli-list-update-issue1104×726 19 KB

7

The problem is still the same: in my environment, with the same data model, with several ConfD versions including 8.0.6, the behavior is as expected, i.e. a new empDetails entry is created and the old one is kept intact. So it must be something in your environment. Possible options how to continue:

  • Try different terminal emulator. Possibly, your terminal emulator and ConfD CLI somehow don’t understand each other and ConfD completes test1234 to test12345 (although, in such weird case I would expect the completion would be visible in your interaction).

  • Start with a simple ConfD project setup, such as the one from the 1-2-3 introductory example, add your employee-config container to it, try to reproduce. If the behavior is ok, look for differences between the two setups. (Not sure what to do if the behavior is not ok though.)

  • Add tailf:cli-no-key-completion to your empDetails list - that should fix / work around the problem, at least for that single list.

8

@mvf have you tried the same keys? first test12345 and then test1234 ?. because the issue is only if the new key is a prefix of any previous key.

9

Yes, I tried the exact sequence of commands as in your screenshot.