[vpp] SAIVPP unit-test harness (docker-sai-test-vpp) + devdocs#1950
[vpp] SAIVPP unit-test harness (docker-sai-test-vpp) + devdocs#1950nicholasching wants to merge 33 commits into
Conversation
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
…test Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
…dog, --relax Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
…ature and restarting backend per group Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
…ugging Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
UT-harness portion of the L3-over-LAG forwarding fix: run_test.sh assigns the DUT-side connected IPs to each LAG (be<N>) and SVI (bvi<vlan>) so routed-to-LAG /SVI traffic forwards in the standalone PTF environment. The backend portion (SwitchVppFdb.cpp) is in the VPP SAI backend PR. Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
73630af to
02b11fa
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
…SER) - gen_compatibility_matrix.py: prefer defusedxml for parsing PTF JUnit XML (XXE-hardened), with a stdlib fallback; input is our own local test output. - Dockerfile: annotate the root entrypoint with a nosemgrep justification — the --privileged harness must run as root to start VPP/Redis/saiserver and manage veth/AF_PACKET; it is a disposable test container, never a deployed service. Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
02b11fa to
4618cda
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Satisfy tests/checkwhitespace.sh (Azure Build amd64 gate). Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Hi Fred (@yue-fred-gao), the I have attached the results below: |
PortChannel netdev creation and LAG/SVI connected-IP assignment now run from sai_test config helpers (vpp_ut_support.py) when each LAG or RIF is created, instead of global run_test.sh startup/watchdog loops. Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| COPY SAI/test/ptf /opt/ptf | ||
| COPY SAI/test/sai_test /sai_test | ||
| COPY .azure-pipelines/docker-sai-test-vpp/vpp_ut_support.py /sai_test/config/vpp_ut_support.py | ||
| COPY .azure-pipelines/docker-sai-test-vpp/harness_sai_test/overrides/lag_configer.py /sai_test/config/lag_configer.py |
There was a problem hiding this comment.
This creates maintenance debt. If the one in sai_test is modified and creates a new dependency from certain test case, the "overrides" may become incompatible. One option is to modify sai_test lag_configer.py. It can be based on some env or config option like SIMULATE_SONIC. It is not necessary to be vpp specific.
There was a problem hiding this comment.
This reply consolidates this thread with #1950 (comment)
I agree, this creates two sources of truth. I've moved the PortChannel and LAG/SVI-IP setup out of the harness overrides and into sai_test, gated by a SIMULATE_SONIC option, disabled by default. As a result, the harness no longer needs to overlay sai_test, and run_test.sh just configures SIMULATE_SONIC=1 instead.
The sai_test change is a separate SAI PR (opencomputeproject/SAI#2316). The changes in SAI were made to be platform agnostic to respect the shared framework, therefore, VPP operations are passed in from the harness as a command template rather than hardcoding vppctl in sai_test.
I've re-validated the full integration of the changes made across (#1950, #1951, #1952, and the 4 SAI PRs) and verified there are no regressions against the 34-PASS baseline.
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
…f using SAI teardown Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
…MULATE_SONIC Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
641e9de to
e57cb6e
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Description of PR
Summary:
Adds the self-contained Docker harness (
docker-sai-test-vpp) that runs the upstream OCPsai_testPTF suite against the real VPP SAI backend (libsaivs) in one container — VPP +saiserver+ PTF + veth/AF_PACKET topology — and produces a per-test compatibility matrix. This is test scaffolding only (everything under.azure-pipelines/docker-sai-test-vpp/); it does not touch any production/runtime code, so it cannot affect existingsonic-sairedisfunctionality. Reviewers can start at.azure-pipelines/docker-sai-test-vpp/README.mdandrun_test.sh.Fixes # (N/A — no upstream issue)
Type of change
Approach
What is the motivation for this PR?
There was no in-tree way to run the OCP
sai_testsuite against the VPP SAI backend and track per-test coverage. This harness provides that, plus the development docs and compatibility matrices used to drive the backend fixes.How did you do it?
Added under
.azure-pipelines/docker-sai-test-vpp/:Dockerfileandrun_test.sh(orchestrates Redis → veth/PortChannel topology → VPP → saiserver → PTF), plus T0 config (sai.profile,lanemap.ini,port-map.ini,ptf-port-map.ini) andgen_compatibility_matrix.py.saiserverprocess,run_test.shgroups tests by theirsetUpconfig signature and restarts the backend per group, so one container can run any mix of tests.ISOLATE_EACH_TEST(default on): run each test in its own group with a fresh backend + own config to eliminate cross-test config-reuse contamination; set0for faster grouped runs.run_test.shassigns the DUT-side connected IPs to each LAG (be<N>) and SVI (bvi<vlan>) so routed-to-LAG/SVI traffic forwards in the standalone PTF environment (the backend portion is in the backend-fixes PR).--debugrun forvppctlinspection.devdocs/,demodocs/, andresults/compatibility matrices;.gitignorefor generated artifacts.How did you verify/test it?
Running the harness against
sai_route_test/sai_rif_test/sai_neighbor_test/sai_ecmp_testproduces a compatibility matrix (current state: 34 PASS, captured indevdocs//results/). The harness is self-contained and does not build or run any production code.Any platform specific information?
VPP platform test infrastructure only; isolated under
.azure-pipelines/docker-sai-test-vpp/. No impact on thesonic-sairedisbuild or runtime behavior.Documentation
This PR adds the harness
README.mdplus rolling/dated progress notes and deep-dive debug logs under.azure-pipelines/docker-sai-test-vpp/devdocs/and demo docs underdemodocs/.