Notification wrongly sent while same configuration is added

NETCONF
1

Hi,

I am updating an already existing configuration with the same value and I expect to receive no notification for this.
Instead I receive notification (MOP_MODIFIED) for this key path.
The update is done via a netconf message using replace command.
I have noticed though that if I use merge then no notification is returned suggesting that the value is already there.
If this is the case why replace triggers notification? Are you aware of any case this could happen?

Thank you in advance for your support.

2

Hi,

If the configuration exists, neither nc:operation=“replace” or “merge” will trigger a subscriber notification.
Did you try this on a single leaf? Or what is your use case? Perhaps you can provide us with a small yang model so that we can reproduce the issue?

Thanks

3

Hi,

Thank you for your help. The use case is quite complicated and in my attempt to provide a simplified yang
I can no longer reproduce the issue. I will try to mimic my use case and provide you a yang file that reproduces the issue.

BR,
Dimitra

4

Hi ,

I was able to reproduce the case using the load replace ntas-example.xml command:

YANG:
`module example {
yang-version 1;
namespace
“http://foo.com/foobar/test-example”;

prefix test-example;

organization
    "Organization name";

description "This is the description";

revision 2016-01-15 {
    description "Initial revision.";
}

container cont-1 {
    list list-1 {
        key key-1;
        leaf key-1 {
            type string;
        }
        container cont-2 {
            list list-2 {
                key key-2;
                leaf key-2 {
                    type string;
                }
                container cont-3 {
                    when "../key-2 = 'keytwoone'";
                    leaf-list list-3 {
                        type string;
                        ordered-by "user";
                        min-elements "1";
                    }
                }
            }
        }
    }
}

}`

XML:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <cont-1 xmlns="http://foo.com/foobar/test-example">
    <list-1>
      <key-1>keyoneone</key-1>
      <cont-2>
        <list-2>
          <key-2>keytwoone</key-2>
          <cont-3>
            <list-3>one</list-3>
            <list-3>two</list-3>
          </cont-3>
        </list-2>
        <list-2>
          <key-2>keytwotwo</key-2>
        </list-2>
      </cont-2>
    </list-1>
  </cont-1>
</config>

using the notification API I see:

commit on db 2 from user admin usid 12
ITER /cont-1/list-1{keyoneone} modified 
ITER /cont-1/list-1{keyoneone}/cont-2/list-2{keytwotwo} modified

Please note that I get no new notification in case of load merge ntas-example.xml

Can you please check?

Thank you

5

Hi,

Thank you for the very good example.

Looks like a corner case bug. Please report it to Tail-f support via RT.
Meanwhile, suggestions for workarounds.

  • Remove the min-elements statement
  • Move the when statement inside list-3
  • Replace the min-elements statement with a must statement:
container cont-1 {
    list list-1 {
        key key-1;
        leaf key-1 {
            type string;
        }
        container cont-2 {
            list list-2 {
                key key-2;
                leaf key-2 {
                    type string;
                }
                container cont-3 {
                    when "../key-2 = 'keytwoone'";
                    must "boolean(./list-3)" {
                      error-message
                      "list-3 must not be empty";
                    }
                    leaf-list list-3 {
                        type string;
                        ordered-by "user";
                    }
                }
            }
        }
    }
}
6

Hi again,

We have made the proposed WA but the subscription socket still sends some kind of notification.
From the developerLog when level is set to trace I get :
> 9-Mar-2017::11:44:07.783 netconf-server confd[68]: confd commit progress db=candidate usid=16 thandle=42: entering validate phase for candidate…

<DEBUG> 9-Mar-2017::11:44:07.785 netconf-server confd[68]: confd commit progress db=candidate usid=16 thandle=42:   validate: grabbing transaction lock...
<DEBUG> 9-Mar-2017::11:44:07.785 netconf-server confd[68]: confd commit progress db=candidate usid=16 thandle=42:  ok
<DEBUG> 9-Mar-2017::11:44:07.937 netconf-server confd[68]: confd commit progress db=candidate usid=16 thandle=42: entering write phase for candidate...
<DEBUG> 9-Mar-2017::11:44:07.978 netconf-server confd[68]: confd commit progress db=candidate usid=16 thandle=42: entering prepare phase for candidate...
<DEBUG> 9-Mar-2017::11:44:07.979 netconf-server confd[68]: confd commit progress db=candidate usid=16 thandle=42: entering commit phase for candidate...
<DEBUG> 9-Mar-2017::11:44:07.980 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40: entering validate phase for running...
<DEBUG> 9-Mar-2017::11:44:07.980 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:   validate: grabbing transaction lock...
<DEBUG> 9-Mar-2017::11:44:07.980 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:  ok
<DEBUG> 9-Mar-2017::11:44:07.981 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:   validate: creating rollback file...
<DEBUG> 9-Mar-2017::11:44:07.988 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:  ok
<DEBUG> 9-Mar-2017::11:44:07.989 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:   validate: run transforms and transaction hooks...
<DEBUG> 9-Mar-2017::11:44:07.989 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:  ok
<DEBUG> 9-Mar-2017::11:44:07.990 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:   validate: pre validate...
<DEBUG> 9-Mar-2017::11:44:08.017 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:  ok
<DEBUG> 9-Mar-2017::11:44:08.017 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:   validate: run validation over the change set...
<DEBUG> 9-Mar-2017::11:44:08.018 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:   validate: validation over the change set done
<DEBUG> 9-Mar-2017::11:44:08.019 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:   validate: run dependency-triggered validation...
<DEBUG> 9-Mar-2017::11:44:08.055 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:   validate: dependency-triggered validation done
<DEBUG> 9-Mar-2017::11:44:08.056 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40: entering write phase for running...
<DEBUG> 9-Mar-2017::11:44:08.056 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:   cdb: write_start
<DEBUG> 9-Mar-2017::11:44:08.061 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40: entering prepare phase for running...
<DEBUG> 9-Mar-2017::11:44:08.061 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:   cdb: prepare
<DEBUG> 9-Mar-2017::11:44:08.061 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:   cdb: all prepare subscription notifications acknowledged
<DEBUG> 9-Mar-2017::11:44:08.062 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40: entering commit phase for running...
<DEBUG> 9-Mar-2017::11:44:08.062 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:   cdb: commit
<DEBUG> 9-Mar-2017::11:44:08.065 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:   cdb: delivering commit subscription notifications at prio 1
<DEBUG> 9-Mar-2017::11:44:08.213 netconf-server confd[68]: devel-cdb connect from /usr/bin/python
<DEBUG> 9-Mar-2017::11:44:08.213 netconf-server confd[68]: devel-cdb client /usr/bin/python has pid 45/7
<DEBUG> 9-Mar-2017::11:44:08.213 netconf-server confd[68]: devel-cdb inactive client /usr/bin/python closed
<DEBUG> 9-Mar-2017::11:44:08.214 netconf-server confd[68]: confd commit progress db=running usid=10 thandle=40:   cdb: all commit subscription notifications acknowledged

But I do not have any actual configuration change coming from the subscription socket.
In addition, behavior is different when load merge is performed.
As you see below commit is not accepted and devel.log has no entries.

admin@netconf-server 11:43:20% load replace config.xml
[ok][2017-03-09 11:43:44]
[edit]
admin@netconf-server 11:43:44% commit
Commit complete.
[ok][2017-03-09 11:44:08]
[edit]
admin@netconf-server 11:44:08% load merge config.xml
[ok][2017-03-09 11:46:04]
[edit]
admin@netconf-server 11:46:04% commit
No modifications to commit.

Can you please check?

Thank you,
Dimitra

7

From what I can read in your log, you load replace commit the config to an empty db, and hence your subscriber is triggered.
Then you load merge commit the same config that you just committed, so there are no modifications to commit, and hence your subscriber is not triggered.
Seems reasonable, or did I miss something?

8

Hi cohult,

No the cdb has data and actually it has exactly the same configuration I try to add. How do you conclude that my db is emlty?

I just did them now in reverse order and problem is the same:

[root@netconf-server /]# confd_cli -u admin
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on netconf-server
admin@netconf-server 14:33:49> configure
Entering configuration mode private
[ok][2017-03-09 14:33:50]

[edit]
admin@netconf-server 14:33:50% load merge config.xml
[ok][2017-03-09 14:33:57]

[edit]
admin@netconf-server 14:33:57% commit
No modifications to commit.
[ok][2017-03-09 14:34:00]

[edit]
admin@netconf-server 14:34:00% load replace config.xml
[ok][2017-03-09 14:34:27]

[edit]
admin@netconf-server 14:34:27% commit
Commit complete.
[ok][2017-03-09 14:34:31]

Thank you,
Dimitra

9

$ cat example.yang

module example {
  yang-version 1;
  namespace
    "http://foo.com/foobar/test-example";

  prefix ex;

  organization
    "Organization name";

  description "This is the description";

  revision 2016-01-15 {
    description "Initial revision.";
  }

  container cont-1 {
    list list-1 {
      key key-1;
      leaf key-1 {
        type string;
      }
      container cont-2 {
        list list-2 {
          key key-2;
          leaf key-2 {
            type string;
          }
          container cont-3 {
            when "../key-2 = 'keytwoone'";
	    must "boolean(./list-3)" {
	      error-message
		"list-3 must not be empty";
	    }
	    leaf-list list-3 {
	      type string;
	      ordered-by "user";
	    }
	  }
	}
      }
    }
  }
}

$ cat config.xml

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <cont-1 xmlns="http://foo.com/foobar/test-example">
    <list-1>
      <key-1>keyoneone</key-1>
      <cont-2>
        <list-2>
          <key-2>keytwoone</key-2>
          <cont-3>
            <list-3>one</list-3>
            <list-3>two</list-3>
          </cont-3>
        </list-2>
        <list-2>
          <key-2>keytwotwo</key-2>
        </list-2>
      </cont-2>
    </list-1>
  </cont-1>
</config>

Demo

$ confd_cli -u admin

admin connected from 127.0.0.1 using console
> config
Entering configuration mode private
% load replace config.xml
% commit
Commit complete.
% load merge config.xml  
% commit                 
No modifications to commit.
% load replace config.xml
% commit                 
No modifications to commit.
% load merge config.xml  
% commit               
No modifications to commit.
% load replace config.xml
% commit                 
No modifications to commit.
% load replace config.xml
% commit                 
No modifications to commit.