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.
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.
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.
Please check if this information can be added in the seperate yaml file for each testbed.
There was a problem hiding this comment.
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.
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