-
Notifications
You must be signed in to change notification settings - Fork 750
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
Update fabric test plan #5678
Update fabric test plan #5678
Conversation
@arlakshm for awareness |
/Azp run Azure.sonic-mgmt |
Commenter does not have sufficient privileges for PR 5678 in repo Azure/sonic-mgmt |
/Azp run Azure.sonic-mgmt |
Commenter does not have sufficient privileges for PR 5678 in repo Azure/sonic-mgmt |
|
||
The above diagram illustrates an example system under test. Every forwarding ASIC is connected to every fabric ASIC. | ||
|
||
The expected fabric link status is stored in the last section of testbed.yaml file, which is called fabric_link_toplogy. The expected status is provided per host and per ASIC, and the format is as follows: |
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.
Please specify if this check is expected to be done on all line cards and sup as well.
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.
The check is done for both linecards and fabric cards on sup. I also updated document with this information
As this is to model the fabric links with software/defined in yaml file, is this applicable for packet based chassis too? |
peer_status: <connected/not_connected> | ||
``` | ||
|
||
Initially, testbed.yaml will contain fabric link status, such as whether or not links are connected. In the future, this information may be extended to contain fabric link connection information. |
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.
Please check if this information can be added in the seperate yaml file for each testbed.
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.
The the fabric link map information is generated dynamically when run the test based on which slot the card is inserted in the system , which type of cards ( sku ), and all these information is in the testbed.yaml file now, and we can get the information while generating the testbed.yaml file and the same time update the fabric topology into it. If they are in separate files, then we will need to get the information from processing the testbed.yaml and then generate the fabric topology into a different files, this can be done , but it will taking longer time also need to parse the same information several times . So we want to double check here if we still want to have the fabric topology information in a separate yaml file ? thank you !
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.
Discussed with Arvind, the information will be added in separate yaml files for each type of cards.
/easycla |
Hi @jfeng-arista, please fix the conflicts |
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
/easycla |
Description of PR
Summary: Update fabric test plan
Fixes # (issue)
Type of change
Back port request
Approach
What is the motivation for this PR?
How did you do it?
How did you verify/test it?
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation