[CPO] Add library function to parse cpo.json - #28077
Conversation
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
00aa8b8 to
162561e
Compare
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Brian Gallagher <bgallagher@nexthop.ai>
Signed-off-by: Brian Gallagher <bgallagher@nexthop.ai>
Signed-off-by: Brian Gallagher <bgallagher@nexthop.ai>
162561e to
842eacc
Compare
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
aditya-nexthop
left a comment
There was a problem hiding this comment.
LGTM, left a few nits.
Signed-off-by: Brian Gallagher <bgallagher@nexthop.ai>
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). 1 pipeline(s) were filtered out due to trigger conditions. |
There was a problem hiding this comment.
Pull request overview
This PR introduces a new sonic_py_common.device_info.get_cpo_data() helper to locate and parse the new cpo.json configuration (preferring HwSKU over platform scope) and adds a unit test validating lookup precedence and lane-field normalization.
Changes:
- Added
get_cpo_data()plus helper functions to locatecpo.jsonand normalize lane-related fields intoList[int]. - Added unit tests covering happy-path parsing/normalization and file lookup precedence/fallback behavior.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/sonic-py-common/sonic_py_common/device_info.py | Adds get_cpo_data() and helper routines for locating and normalizing cpo.json. |
| src/sonic-py-common/tests/device_info_test.py | Adds unit tests for get_cpo_data() behavior, normalization, and path precedence. |
Signed-off-by: Brian Gallagher <bgallagher@nexthop.ai>
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
| } | ||
| } | ||
| """ | ||
| for device in cpo_data.get('devices', {}).values(): |
There was a problem hiding this comment.
@bgallagher-nexthop how is the information in this file tied back to the cpo object? For eg, the i2c path is not being considered for eeprom path which say will be used by cpoutil to do hexdump?
There was a problem hiding this comment.
we have elsfp and oe object for each logical port, shouldn't these parsed information reflect in those? i.e this file is the source of truth for the platform from where these objects derive the mapping information per logical port.
There was a problem hiding this comment.
otherwise platform will hardcode thse mapping in their own .py file which defeats the purpose.
There was a problem hiding this comment.
This function is only for normalization purposes, just to make the data easier to use -- strings like "1,2,3" just get normalized into an actual array [1,2,3]so clients don't have to do this normalization themselves
The info in this file is intended to be used by vendors in their platform code:
- when creating CPO objects, this file is the source-of-truth for which ports should have
CpoBaseobjects created for them (see [CPO] Extend ChassisBase to support CPO ports sonic-platform-common#700 for where it is used) - it can contain platform specific information like i2c path information if the vendor needs it. not all vendors will use this though -- PDDF users will not do so for instance
- xcvrd will use this file to map logical interfaces and physical ports to CPO devices (i.e "Ethernet0 and Ethernet8 are both using OE1")
Signed-off-by: aditya-nexthop <aditya@nexthop.ai>
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Why I did it
The "Port Mapping for CPO" HLD introduces a new file:
cpo.json. It also stipulates that a library function will be introduced to parse this JSON file for vendors to use in their platform code.This PR adds that function to parse the
cpo.jsonfile and return a dictionary that vendors can use in platform code.How I did it
A new function is added called
get_cpo_data(). It does the following:How to verify it
A unit-test has been added.
Which release branch to backport (provide reason below if selected)
Tested branch (Please provide the tested image version)
Description for the changelog
[CPO] Add library function to parse cpo.json