[TRNSPRTPCE-249] Device listener fails to read Honeynode datastore after receiving notification change Created: 01/Apr/20  Updated: 08/Mar/21

Status: Open
Project: transportpce
Component/s: None
Affects Version/s: None
Fix Version/s: Aluminium, Silicon

Type: Bug Priority: Medium
Reporter: Javier Errea Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File DeviceListener.java     File notification_change_error.log    
Issue Links:
Duplicate
is duplicated by TRNSPRTPCE-251 Netconf connection failing when using... Open

 Description   

I am trying to do some handling of device notification change in the Device Listener of the networkmodel module.

I am working with emulated Honeynode 1.2.1, and I trigger an <edit-config> netconf operation from an external netconf session. Once this operation is commited, the change is received at the controller, but when I try to retrieve the device configuration I get the errors and warnings obtained in the log attached.

The code written for the device listener is attached as well. 

As far as I understand every time a new device is connected to the controller a new device listener is created to listen to the events triggered from that new device. So, I dont know if I have to add something to the blueprint.xml of the networkmodel module.

Also, the YANG model for the notification change doesn't include any information about the device that sent the notification, but I would like to treat the notifications per device.

I am not very sure about how to target this implementation as I am still getting familiar with opendaylight and transportpce. Any suggestion/feedback will be very helpful.



 Comments   
Comment by Daniel De La Rosa [ 30/Apr/20 ]

guillaume.lambert if this is a duplicate? can we just close it? and is it really a blocker?

Comment by Guillaume Lambert [ 12/May/20 ]

danieldelarosa not a blocker at this stage, I change the priority to high.

Comment by Jamo Luhrsen [ 18/May/20 ]

This feels similar to NETCONF-666. Essentially, an rpc-error is seen in the reply from the netconf server
and after the device timeout expires, the device is disconnected and reconnected. The logs do not
match exactly, but the symptoms seem similar.

Comment by Guillaume Lambert [ 20/May/20 ]

Thanks Jamo. It is worth to mention it.
+ cbetoule and gthouenon

Generated at Wed Feb 07 20:42:36 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.