-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[SONiC] Design and test plan document for refactoring port_config.ini parse code #613
Conversation
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.
LGTM
[portconfig.py](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-config-engine/portconfig.py) is defined in [sonic-config-engine](https://github.com/Azure/sonic-buildimage/tree/master/src/sonic-config-engine). In order to reuse this module: | ||
|
||
1. For those modules who have build-time unit test, they may declare sonic-config-engine as a build-time dependency in make rules. | ||
2. For those modules who are installed in a docker, we must make sure sonic-config-engine is also installed in that docker, for example, pmon docker need reuse portconfig.py and it has sonic-config-engine installed. |
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.
I have had the idea for a while now that portconfig.py, minigraph.py, etc. should be pulled out of the sonic-config-engine package and placed in their own package. Like we now have sonic-daemon-base
, I believe we should have a package like, sonic-utils
(however, we need a different name because this is too similar to sonic-utilities
) which is basically a library of functionality that is used throughout SONiC.
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.
Great point. Should we do it within this feature or a seperate feature?
@Junchao-Mellanox Can you please take a look at these PRs to see if your points were already covered? sonic-net/sonic-utilities#767 |
@Junchao-Mellanox could you response @zhenggen-xu 's comment #613 (comment) ? |
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.
LGTM, please address @zhenggen-xu's question before merging please
Yes, those PRs cover a lot of the current design except that:
|
… parse code (sonic-net#613) * add design document to refactor port config logic * Add a simple test plan for this enhancement * Add description for changing port index start from 1 * Add more detail for the test plan
Why I did this?
portconfig.py is designed to manage and parse port_config.ini file. But there are a few existing code implement its own logic to get port_config.ini path or parse the content of port_config.ini. We should try re-use portconfig.py as possible as we can.
What I did?