Repository navigation
US-27 — Analyse a vendor that is not Cisco, end to end #320
Description
As an engineer with a mixed estate, I want Arista, NX-OS and Juniper to work as well as IOS does.
Acceptance criteria
vendor-asajoins the other three: a deliberate fault, and an end-to-end test that finds it. It is the only fixture Batfish reports asPARTIALLY_UNRECOGNIZED, so this depends on resolving parse strictness- Any check that is IOS-specific says so as
status="error", per F-4 - A per-vendor support table in
README.md, generated rather than typed -- nothing a user reads currently says which vendors work - The table distinguishes parses from produces findings, because
tests/test_vendor_fixtures.pyis emphatic that these are different claims
Why this is in the milestone
RESCOPED after measuring, and the original scope was wrong in our favour twice. Discussion #296 asked for "the three existing vendor fixtures" to run through the full pipeline. There are four fixtures, and three of them already do -- pytest tests/test_vendor_fixtures.py passes 10 tests against real Batfish today. What remains is vendor-asa, which parses only partially, and the fact that no user-facing document says any of this.
Epic: Vendors | Size: L | Assigned: @patelankeet2
Story and acceptance criteria come from Discussion #296 unchanged, so anyone who reviewed the discussion has already reviewed this issue.
Part of Phase 3 - market readiness. The distribution of this milestone is deliberately uneven and is explained in docs/design/phase-3-backlog.md and on #249.
Activity
ARSH871-bot commentedon Sep 10, 2026
@patelankeet2 — I have rescoped this before you started it, because I checked the premise against
mainand the original scope was wrong in our favour, twice.This issue was created from Discussion #296, which asked for "the three existing vendor fixtures run through the full pipeline, not just parsing". Measured this morning:
So three vendors already run the full pipeline and produce a real finding. That criterion was asking for work that had been done — largely by you.
The fixture that is genuinely outstanding is
vendor-asa. Its own test file records why:and
find_parse_problems()currently treats anything other thanPASSEDas fatal, which is open decision 1 inCLAUDE.md. So this story now depends on that decision rather than pretending it does not.What the issue asks for now:
vendor-asabrought up to the standard of the other three, and a generated per-vendor support table inREADME.md— because nothing a user reads currently says which vendors work. The table has to distinguish parses from produces findings, sincetest_vendor_fixtures.pyis emphatic that those are different claims:Why I am writing this up rather than quietly editing
Two wrong numbers reached this issue because I copied #296's wording faithfully instead of checking it. Copying a claim faithfully is not the same as checking it, and the whole argument of this project is that those get confused. It is the same shape as the A-2 ratification table and the stale PF Sense blocker list: a sentence that was true when written, carried forward by someone who had no reason to doubt it.
The under-claim is the part worth noticing. An overclaim gets caught when somebody tries it. An underclaim just quietly wastes a sprint re-doing finished work, and nothing objects.
docs/design/phase-3-backlog.mdon #348 is corrected to match — its Vendors section previously said "Three vendor fixtures exist. One vendor has ever been proven end to end." Both halves were wrong.US-27 asked for work that main had already done
Fix: classify() must not guess "Parses cleanly" for a result it canno…
vendor-asa joins the vendor fixture suite (#320)
Generate a vendor support table into README.md (#320)
Pin README's vendor table as generated, not typed (#320)
Fix: classify() must not guess "Parses cleanly" for a result it canno…
Merge main into feature/320-vendor-asa-support-table
Merge pull request #360 from ARSH871-bot/feature/320-vendor-asa-suppo…