Skip to content

[telemetry] Support both libyang1 and libyang3 in validate_yang_events.py#25508

Open
bingwang-ms wants to merge 1 commit into
sonic-net:masterfrom
bingwang-ms:fix/validate-yang-events-libyang1-compat
Open

[telemetry] Support both libyang1 and libyang3 in validate_yang_events.py#25508
bingwang-ms wants to merge 1 commit into
sonic-net:masterfrom
bingwang-ms:fix/validate-yang-events-libyang1-compat

Conversation

@bingwang-ms

Copy link
Copy Markdown
Collaborator

Description of PR

Summary:
On SONiC 202511 and earlier, the DUT has libyang1 (Python module yang, package python3-yang via SWIG binding). Starting with SONiC 202512+, libyang3 (Python module libyang) will be available. validate_yang_events.py was written for libyang3 and fails with ModuleNotFoundError: No module named libyang on 202511 DUTs.

This PR adds a try/except fallback so the script works with either libyang version. The libyang1 API uses yang.Context with ctx.parse_module_path() and ctx.parse_data_mem(), while libyang3 uses libyang.Context with ctx.parse_module() and ctx.parse_data(). Both paths are now supported.

Fixes failing test_events on Nokia TH6 (SONiC 202511) and other platforms running SONiC ≤202511.

Type of change

  • Bug fix

Back port request

  • 202511
  • 202505

Approach

What is the motivation for this PR?

validate_yang_events.py uses libyang3 Python API but SONiC 202511 DUTs only have libyang1. This causes test_events to fail with ModuleNotFoundError: No module named libyang.

How did you do it?

Added a try/except import block: try import libyang (libyang3), fall back to import yang as libyang (libyang1). Added an _LY3 boolean flag to branch the API calls that differ between libyang1 and libyang3.

How did you verify/test it?

Ran test_events on Nokia TH6 testbed (SONiC 202511/Debian 13). Test PASSED.

Any platform specific information?

Affects all platforms running SONiC ≤202511 with libyang1.

Supported testbed topology if it's a new test case?

N/A

Documentation

N/A

…s.py

SONiC 202511 (Debian 13) ships libyang1 Python bindings as the 'yang'
module (python3-yang package). SONiC 202512+ will have libyang3 Python
bindings as the 'libyang' module after sonic-buildimage#26584 lands.

The previous commit (c6fb27f) ported the script from 'import yang' to
'import libyang', which works on 202512+ but breaks on 202511 with
ModuleNotFoundError: No module named 'libyang'.

Add a try/except import fallback so the script works on both:
  - libyang3 (import libyang): uses the new API (IOType.FILEPATH,
    parse_data_mem with keyword args)
  - libyang1 (import yang): uses the old API (LYS_IN_YANG,
    LYD_JSON / LYD_OPT_CONFIG | LYD_OPT_STRICT)

Verified on Nokia IXR7220-H6 running SONiC.20251210.07 (202511).

Signed-off-by: Bing Wang <bingwang@microsoft.com>
@mssonicbld

Copy link
Copy Markdown
Collaborator

/azp run

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@mssonicbld mssonicbld added Request for 202511 branch Request to backport a change to 202511 branch Request for 202505 branch labels Jun 20, 2026
@mssonicbld

Copy link
Copy Markdown
Collaborator

This PR has backport request for branch(es): 202511,202505.
Added label(s) for branch(es) 202511,202505.

---Powered by SONiC BuildBot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Request for 202505 branch Request for 202511 branch Request to backport a change to 202511 branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants