Some config merge errors are not reported back by napalm-sros:

[rinsekloek]

When deploying a new router I stumbled upon the issue that a config merge error is not reported back via the Napalm SROS module in Peering Manager, but when I do the config change manually Incuding commit, I do get these messages. Is this expected behaviour ? I would like to get feedback If my commit is not working.

Config merge from Peering manager via Napalm: (No error message is reported back, but I would expecet the message of policy-variable definition-missing )

2023-10-28 08:42:57,825 session.py _dispatch_message line 78 DEBUG:  [host sros02 session-id 44] dispatching message to listener: <ncclient.operations.rpc.RPCReplyListener object at 0x7fccae25bf70>
2023-10-28 08:42:57,826 rpc.py callback line 255 DEBUG:  [host sros02 session-id 44] Delivering to <ncclient.operations.session.CloseSession object at 0x7fccae1f7220>
2023-10-28 08:42:57,826 session.py _dispatch_message line 78 DEBUG:  [host sros02 session-id 44] dispatching message to listener: <ncclient.transport.session.NotificationHandler object at 0x7fccae25bcd0>
2023-10-28 08:42:57,826 parser.py _parse11 line 233 DEBUG:  [host sros02 session-id 44] _parse11: saving back rest of message after 44 bytes, original size 44
2023-10-28 08:42:57,827 parser.py _parse11 line 240 DEBUG:  [host sros02 session-id 44] _parse11: ending
2023-10-28 08:42:57,827 ssh.py run line 529 DEBUG:  [host sros02 session-id 44] Broke out of main loop, error=SessionCloseError('Unexpected session close')
2023-10-28 08:42:57,827 session.py _dispatch_error line 85 DEBUG:  [host sros02 session-id 44] dispatching error to <ncclient.operations.rpc.RPCReplyListener object at 0x7fccae25bf70>
2023-10-28 08:42:57,828 session.py _dispatch_error line 85 DEBUG:  [host sros02 session-id 44] dispatching error to <ncclient.transport.session.NotificationHandler object at 0x7fccae25bcd0>
2023-10-28 08:42:57,829 __init__.py close_napalm_device line 1248 DEBUG:  closed connection with sros02
2023-10-28 08:42:57,829 rpc.py _request line 352 INFO:  [host sros02 session-id 44] Requesting 'CloseSession'
2023-10-28 08:42:57,830 jobs.py log line 182 INFO:  Configuration installed.
2023-10-28 08:42:57,843 worker.py perform_job line 1463 INFO:  default: Job OK (7e41eb58-e0ed-4b3f-81a4-788b3ecda791)
2023-10-28 08:42:57,843 worker.py perform_job line 1472 INFO:  Result is kept for 500 seconds

Manual config change on Router: (There were some policy-variable definition-missing , clear error output)

A:admin@sros2# commit
  MINOR: MGMT_CORE #224: configure policy-options policy-statement "PMGR-PRIVATE-PEERING-IN-V4" entry 10 from policy - Entry does not exist - subpol policy-statement name "PEER-IN-V4", policy-variable definition-missing or out-of-range "@COMMUNITY@" - configure policy-options policy-statement "PMGR-PRIVATE-PEERING-IN-V4" entry 10
  MINOR: MGMT_CORE #224: configure policy-options policy-statement "PMGR-TRANSIT-IN-V4" entry 10 from policy - Entry does not exist - subpol policy-statement name "PEER-IN-V4", policy-variable definition-missing or out-of-range "@COMMUNITY@" - configure policy-options policy-statement "PMGR-TRANSIT-IN-V4" entry 10
  MINOR: MGMT_CORE #224: configure policy-options policy-statement "PMGR-TRANSIT-LGI-IN-V4" entry 10 from policy - Entry does not exist - subpol policy-statement name "PEER-IN-V4", policy-variable definition-missing or out-of-range "@COMMUNITY@" - configure policy-options policy-statement "PMGR-TRANSIT-LGI-IN-V4" entry 10

[hellt]

/cc @jbemmel

[rinsekloek]

I have found the reason why this error was not reported. (Commit error handling dit not work at all for my SROS lab )

This was the error:

 MINOR: MGMT_CORE #224: configure policy-options policy-statement "PMGR-PRIVATE-PEERING-IN-V4" entry 10 from policy 
 - Entry does not exist - subpol policy-statement name "PEER-IN-V4", policy-variable definition-missing or out-of-range "@COMMUNITY@" - configure policy-options policy-statement "PMGR-PRIVATE-PEERING-IN-V4" entry 10

That matched this regex sros.py lines 348,349: (The # makes it looks like it's a cmd_line)
if self.cmd_line_pattern_re.search(item):
continue

So I changed the code a bit to first match the error regex and later the cmd_line (Maybe the whole cmd_line can be left out ?)
I do raise a CommitError now, but Peering Manager only reports the commit error (without the message). I suppose this erorr handling needs to be fixed in Peering Manager

This is the current diff. I added some extra debugging to have more logging.

diff --git a/napalm_sros/sros.py b/napalm_sros/sros.py
index f405725..3ec4c53 100644
--- a/napalm_sros/sros.py
+++ b/napalm_sros/sros.py
@@ -41,6 +41,7 @@ from napalm.base.exceptions import (
     SessionLockedException,
     MergeConfigException,
     ReplaceConfigException,
+    CommitError,
 )
 from napalm.base.helpers import convert, ip, as_number
 import napalm.base.constants as C
@@ -344,15 +345,19 @@ class NokiaSROSDriver(NetworkDriver):
             buff = self._perform_cli_commands(["commit"], True)
             # If error while performing commit, return the error
             error = ""
+            logging.debug(f"Result of cli commit: {buff}")
             for item in buff.split("\n"):
-                if self.cmd_line_pattern_re.search(item):
-                    continue
                 if any(match.search(item) for match in self.terminal_stderr_re):
+                    logging.debug(f"Match error item: {item}")
                     row = item.strip()
                     row_list = row.split(": ")
                     error += row_list[2]
+                if self.cmd_line_pattern_re.search(item):
+                    logging.debug(f"cmd_line_pattern found in {item}")
+                    continue
             if error:
                 print("Error while commit: ", error)
+                raise CommitError("Commit error: %s", error)
         elif self.fmt == "xml":
             self.conn.commit()
             if not self.lock_disable and not self.session_config_lock:

I have pushed this to my fork @ https://github.com/rinsekloek/napalm-sros

[jbemmel]

Thanks, PR applied: #69