netopeer2-cli mixing rpc-reply and notification, corrupting output

[Krisscut]

Version: netopeer2-2.1.62

Hi,

I noticed in a automated test a weird behavior, I assume it comes from netopeer2-cli. In one occasion, netopeer2-cli displayed a notification right at the same time as it received the result from a get rpc

2023-08-09 06:13:54.336 [    INFO] (utils_oran.py:458) 2023-08-09 06:13:54.336262: expect_data: get --filter-xpath /ietf-hardware:*

2023-08-09 06:13:54.493 [    INFO] (utils_oran.py:468) BEFORE: 

<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <hardware xmlns="urn:ietf:params:xml:ns:yang:ietf-hardware">

    <last-changenotification (2023-08-09T06:13:54.480352233+00:00)

<ptp-state-change xmlns="urn:o-ran:sync:1.0">

  <ptp-state>LOCKED</ptp-state>

</ptp-state-change>

>2023-08-09T06:13:46+00:00</last-change>

    <component>

      <name>AHLOA</name>

      <class xmlns:o-ran-hw="urn:o-ran:hardware:1.0">o-ran-hw:O-RAN-RADIO</class>

      <hardware-rev>hw-rev01</hardware-rev>

      <software-rev>oru-sw-r1</software-rev>

      <serial-num>RY150403577</serial-num>

      <mfg-name>NK</mfg-name>

      <model-name>RADIOGEN1</model-name>

      <state>

        <state-last-changed>2023-08-09T06:13:46+00:00</state-last-changed>

        <admin-state>unlocked</admin-state>

        <oper-state>enabled</oper-state>

        <usage-state>active</usage-state>

        <availability-state xmlns="urn:o-ran:hardware:1.0">NORMAL</availability-state>

      </state>

      <label-content xmlns="urn:o-ran:hardware:1.0">

        <model-name>true</model-name>

        <serial-number>true</serial-number>

      </label-content>

      <product-code xmlns="urn:o-ran:hardware:1.0">474331A</product-code>

      <energy-saving-enabled xmlns="urn:o-ran:hardware:1.0">false</energy-saving-enabled>

      <dying-gasp-support xmlns="urn:o-ran:hardware:1.0">false</dying-gasp-support>

      <o-ran-name xmlns="urn:o-ran:hardware:1.0">AHLOA</o-ran-name>

    </component>

    <component>

      <name>P1</name>

      <class xmlns:ianahw="urn:ietf:params:xml:ns:yang:iana-hardware">ianahw:port</class>

      <hardware-rev>hw-p01</hardware-rev>

      <software-rev>sw-p01</software-rev>

      <serial-num>S01234</serial-num>

      <mfg-name>NK</mfg-name>

      <state>

        <state-last-changed>2023-08-09T06:13:46+00:00</state-last-changed>

        <admin-state>unlocked</admin-state>

        <oper-state>enabled</oper-state>

        <usage-state>active</usage-state>

      </state>

      <o-ran-name xmlns="urn:o-ran:hardware:1.0">P1</o-ran-name>

    </component>

    <component>

      <name>P2</name>

      <class xmlns:ianahw="urn:ietf:params:xml:ns:yang:iana-hardware">ianahw:port</class>

      <hardware-rev>hw-p01</hardware-rev>

      <software-rev>sw-p01</software-rev>

      <serial-num>S01234</serial-num>

      <mfg-name>NK</mfg-name>

      <state>

        <state-last-changed>2023-08-09T06:13:46+00:00</state-last-changed>

        <admin-state>unlocked</admin-state>

        <oper-state>disabled</oper-state>

        <usage-state>active</usage-state>

      </state>

      <o-ran-name xmlns="urn:o-ran:hardware:1.0">P2</o-ran-name>

    </component>

  </hardware>

</data>
---------------------------- Captured log teardown -----------------------------

It's worth noting the automation is done through pexpect on top of the netopeer2-cli. In the meantime, this test was modified to have 2 instances of netopeer2-cli to separate the "command session" from the "notification session" but I wanted to share this usecase.

[michalvasko]

Yes, nothing to prevent the data being mixed since the notifications are received and printed in a separate thread. Consider it a CLI limitation.

[Krisscut]

Ok thanks, that's good to know ! Maybe something that could be put somewhere on the documentation in case next users are wondering about it as well.

[michalvasko]

The main purpose of the CLI is for simple interactive NETCONF sessions. On the off-chance this happens to you, it should be fine, not so much when using it in a script and expecting exact output/automated processing.

[Krisscut]

Yes I plan to move to ncclient or something like that in the future, but you know how it is, sometime you have to live with legacy code until the time to refactor comes. 😶