-
Notifications
You must be signed in to change notification settings - Fork 711
Build a python3 wheel with sonic_psu #162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: Qi Luo <[email protected]>
from setuptools import setup | ||
import unittest | ||
|
||
# For python3 wheel, we currently don't need test | ||
# TODO: build python3 wheel of all the dependencies, and remove conditional test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really plan to do this in the future?
It is my understanding that this is a temporary solution until we break the sonic Python modules out into their own package, separate from sonic-utilities, then we will build the modules package for both Python 2 and 3, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. This is an alternative, and we can remove TODO if either is achieved.
…'N/A' (sonic-net#162) Currently, some vendors are using custom transceiver info parsers which do not yet provide the `dom_capability` field in the results of `get_transceiver_info()`. However, PR sonic-net/sonic-platform-daemons#72 introduced storing this value to State DB under the assumption that it would always be present. On platforms where this value is not present, it would cause xcvrd to crash (see issue: sonic-net/sonic-buildimage#6978). This change will prevent a crash if it is not present, and will in turn save `'N/A'` as the `dom_capability` value in State DB.
… internal and nic temperature and voltage (sonic-net#162) * [sonic_y_cable] add support for retreiving firmware info for Y cable, internal and nic tempertaure and voltage This PR provides the necessary infrastructure to add support for getting firmware information running on the three ends of Y cable. Also we get internal and nic side temperature and voltage What is the motivation for this PR? To add the necessary support for fetching firmware info for Y cable, internal and nic temperature and voltage How did you do it? Added the changes in sonic-platform-common module in the y_cable.py file How did you verify/test it? opened a python shell and ran the API's manually and test verified the values are correct. Signed-off-by: vaibhav-dahiya <[email protected]>
…able/disable (sonic-net#162) <!-- Please make sure you've read and understood our contributing guidelines: https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md failure_prs.log skip_prs.log Make sure all your commits include a signature generated with `git commit -s` ** If this is a bug fix, make sure your description includes "closes #xxxx", "fixes #xxxx" or "resolves #xxxx" so that GitHub automatically closes the related issue when the PR is merged. If you are adding/modifying/removing any command or utility script, please also make sure to add/modify/remove any unit tests from the tests directory as appropriate. If you are modifying or removing an existing 'show', 'config' or 'sonic-clear' subcommand, or you are adding a new subcommand, please make sure you also update the Command Line Reference Guide (doc/Command-Reference.md) to reflect your changes. Please provide the following information: --> ## **Summary of Changes** ### **What I did** - Added a new `debug.py` module to handle **SFP diagnostics and debugging**. - Replaced existing **utility methods** with functions from `utilities_common.platform_sfputil_helper`. - Registered `debug` as a subcommand in `sfputil/main.py`. ### **How I did it** - Created a new `debug.py` file under `sfputil/`. - Implemented the `debug` command group with the following subcommands: - `loopback`: Configures SFP loopback modes. - `tx-output`: Enables or disables TX output. - `rx-output`: Enables or disables RX output. - Used helper functions from `utilities_common.platform_sfputil_helper` for better modularity and maintainability. - Updated `sfputil/main.py` to integrate the new `debug` command. ### **How to verify it** UT and deploy changed on a testbed 1. Run the following command to check if `debug` is now available: ```sh sfputil debug --help 2. sfputil debug tx-output Ethernet0 enable 3. sfputil debug rx-output Ethernet0 disable ``` Usage: sfputil debug [OPTIONS] COMMAND [ARGS]... Try "sfputil debug --help" for help. Error: no such option: -h admin@sonic:~$ sudo sfputil debug --help Usage: sfputil debug [OPTIONS] COMMAND [ARGS]... Group for debugging and diagnostic control commands. This command group loads platform-specific utilities and prepares them for use in diagnostic commands. Options: --help Show this message and exit. Commands: loopback Set module diagnostic loopback mode. rx-output Enable or disable RX output on a port. tx-output Enable or disable TX output on a port. admin@sonic:~$ sudo sfputil debug rx-output --help Usage: sfputil debug rx-output [OPTIONS] PORT_NAME [enable|disable] Enable or disable RX output on a port. Options: --help Show this message and exit. admin@sonic:~$ ```
So we can install the wheel in a python3 environment