Joseph Wu

Rename qos queuing-policy to queue-config and fold in default Summary: `config qos queuing-policy <name> queue-id <id> ...` and `config qos default-queue-config <id> ...` were two command verbs for one concept: both call `utils::applyPortQueueConfig()` on the same `cfg::PortQueue` attributes and converge in `ThriftConfigApplier::updatePortQueues()`, differing only in which `SwitchConfig` field receives the resulting `list<PortQueue>`. This merges them into `config qos queue-config <name|default> queue-id <id> <attr> <value>...`, where `default` is a reserved name routing to `SwitchConfig::defaultPortQueues` and any other name to a `SwitchConfig::portQueueConfigs` entry. "Queuing policy" has no backing in FBOSS vocabulary -- a repo-wide search finds it nowhere outside the fboss2 CLI. Thrift is consistent the other way: `typedef string PortQueueConfigName`, `map<PortQueueConfigName, list<PortQueue>> portQueueConfigs`, and `Port.portQueueConfigName`, whose doc comment at `switch_config.thrift:1283-1291` already describes both halves as "port queue config". The sharpest case was `config interface <intf> queuing-policy <name>`, which writes a field literally named `portQueueConfigName`. `config qos policy` / `default-policy` also already exist and refer to the unrelated `cfg::QosPolicy`, so `qos policy` and `qos queuing-policy` read as sibling nouns over different thrift types. Reserving `default` is what keeps the two branches disjoint: `portQueueConfigs` can never acquire a `default` key, so `Port.portQueueConfigName` can never resolve to the default list. On the interface side this makes `config interface <intf> queue-config default` a reset: it clears the port's `portQueueConfigName` rather than binding a name that resolves to nothing. That follows the thrift contract directly -- an unset `portQueueConfigName` already means "use `defaultPortQueues`", so selecting `default` and removing the override are the same operation. A matching `delete interface <intf> queue-config` sharing this implementation is a follow-up. Shared vocabulary moves into `PortQueueConfigUtils`: `QueueConfigName` (was `QueuingPolicyName`, now with `isDefault()`), `QueueIdAndAttributes` (was `QueueConfig`, renamed to avoid colliding with the new `CmdConfigQosQueueConfig` class), `kDefaultQueueConfigName`, and `queueConfigListForWrite()`. This also fixes the previous backwards include, where `CmdConfigQosDefaultQueueConfig.h` reached into `queuing_policy/`. No behavior change to `delete qos default-queue-config`, which still operates on the same `defaultPortQueues` field; it is restructured in a follow-up. Reviewed By: srikrishnagopu Differential Revision: D114937596 fbshipit-source-id: fd1dc2d02ce91b1fe241d0155e1fa744c3b2e42c

Support ASIC config overrides and Agent config parity validation Summary: # Problem Statement `fboss2 config gen agent` previously required ASIC configuration metadata and selected ASIC configuration files exclusively from the generated platform directory. This prevents vendors or platforms without open-source ASIC configuration artifacts from supplying their own configuration for testing. There was also no automated way to compare a newly generated Agent configuration with an existing Configerator or COOP configuration. Direct byte comparison is insufficient because equivalent configurations can differ in JSON formatting, embedded YAML ordering, fields normalized by the current Thrift schema, or known exceptions such as `sw.sdkVersion`. # Solution Add `--asic-config-file` to override the generated ASIC configuration artifact and `--asic-config-type` to explicitly select `key_value`, `json`, or `yaml`. Providing both options bypasses the normal ASIC metadata and generated-file selection. Add Agent configuration parity comparison with three results: `BYTE_MATCH`, `SEMANTIC_MATCH`, and `CONTENT_MISMATCH`. The comparison normalizes Agent configs through the current Thrift schema, canonicalizes embedded YAML and JSON, universally ignores `sw.sdkVersion`, and reports semantic differences or mismatched fields using `jq`-compatible paths. Add `--reference-config-file` to `fboss2 config gen agent` so generation and parity validation can be performed in one command. Content mismatches return a nonzero exit status and are reported as local validation failures without misleading `localhost` or Thrift error messages. Add a table-driven parity test whose initial candidate validates the generated Wedge800BACT `hw_test` profile against its existing materialized configuration. Reviewed By: daiwei1983 Differential Revision: D120229668 fbshipit-source-id: e936c2f87ebc62501b17e44f8423462e31ac0325

Generate data-driven default command args Summary: Generate default command-line arguments from a shared Thrift-backed feature configuration instead of adding new C++ inputs for each feature. Resolve profile defaults and auto-enabled features from config profile, ASIC type, and platform include/exclude conditions; features without auto-enable conditions remain available for explicit platform variants. Seed the generic Agent configuration with the HW-test command-line arguments and their existing Configerator feature names. This keeps the data alongside the forwarding-stack configuration and lets future services reuse the loader. Strictly reject malformed field types, unknown fields, invalid conditions, duplicate arguments, and conflicting values. Add a dedicated data-driven test that discovers every checked-in service configuration, plus Agent generation coverage and build/formatting integration. Reviewed By: daiwei1983 Differential Revision: D118907549 fbshipit-source-id: d92e618045d80dbcc6af6c2e2cd8c040a3957ff5

Centralize port profile changes in PortConfigUtils Summary: # Problem Statement Port-profile validation and mutation are coupled to `CmdConfigInterface` through `ProfileValidator`. This prevents other config-generation workflows from reusing the same platform, optics, speed, and port-subsumption logic without duplicating it. After moving the logic into a strict batch API, repeated CLI interface names were forwarded as duplicate requests even though the command should treat the same interface as one target. The existing `SetProfileMultiInterface` integration test also repeated one interface and reapplied its current profile, so it did not validate a real multi-interface profile change. # Solution Introduce `utility::applyPortProfileChanges` as a reusable atomic batch API in `PortConfigUtils`. It validates every requested profile against the platform mapping and optional QSFP constraints, resolves port speeds, creates missing routed ports, and reports configured ports subsumed by the requested profiles. Requests may select different profiles for different ports, and validation failures leave the original config unchanged. Update `CmdConfigInterface` to retrieve Agent and QSFP inputs and delegate profile application to the shared utility. Keep CLI-specific policy in the command layer: only absent interface ports may be created, subsumed ports are removed, and removals escalate the commit to coldboot. Normalize repeated CLI interface names while preserving their first occurrence so every attribute is applied once per interface. Remove the superseded `ProfileValidator`, migrate its coverage, and keep Buck and OSS CMake definitions aligned. Revise `SetProfileMultiInterface` to select two distinct controlling ports that support the same target profile, require that target to differ from both current profiles, apply it to both ports in one command, and verify both changes. The candidate selection permits subsuming profiles so the test can exercise that behavior when available. Reviewed By: KevinYakar Differential Revision: D126217303 fbshipit-source-id: 3f78d9fdd32ec37d091550decdfe4ff9a779d4b3

Add delete qos queue-config, incl. removing named configs Summary: Completes the `queue-config` surface started in D114937596. `delete qos default-queue-config <id>` only reached `SwitchConfig::defaultPortQueues`, so a named `portQueueConfigs` entry could be created by the CLI but never removed by it. This replaces it with `delete qos queue-config <name|default> [queue-id <id>]`, mirroring the config command's shape. | Command | Behavior | | --- | --- | | `delete qos queue-config default queue-id <id>` | Remove that queue from `defaultPortQueues` | | `delete qos queue-config default` | Clear the whole `defaultPortQueues` list | | `delete qos queue-config <name> queue-id <id>` | Remove that queue from `portQueueConfigs[<name>]` | | `delete qos queue-config <name>` | Remove the whole entry, if no port still references it | `Port.portQueueConfigName` is a plain string with no referential integrity of its own, so removing a bound config would leave those ports naming an entry that no longer exists. Whole-config deletion therefore hard-fails when any port still references the name, listing the offending interfaces and both remedies (`config interface <intf> queue-config <other>` to switch, or `... queue-config default` to fall back). There is deliberately no `--force`: reverting those ports to the default queue config is a different intent than switching them to another one, and only the operator knows which was meant. Three consequences of that rule worth stating, since they are the non-obvious edges: - Removing a single queue from a bound config is allowed. The port's `portQueueConfigName` still resolves, just to a smaller list, so nothing is left dangling. - Deleting the last queue in a named config leaves the entry present but empty, rather than removing it, so per-queue settings can be added back later. - `default` needs no such guard and cannot have one: no port names it explicitly, and every port without a binding falls back to it, so it can never be dangling. Clearing it reverts every unbound port to the ASIC defaults. Adds `findQueueConfigList()` and `portsUsingQueueConfig()` to `PortQueueConfigUtils`. Delete resolves through `findQueueConfigList()` rather than `queueConfigListForWrite()` so a typo'd config name fails instead of silently creating an empty entry. Also fixes stale help text in `CmdDeleteQos` still advertising `default-queue-config` as a subcommand. No commit-level change: D114925860 already moved both the config and delete sides to `AGENT_WARMBOOT`. Reviewed By: srikrishnagopu Differential Revision: D114975810 fbshipit-source-id: e40cbd10720b8799fd3448619c5d48852f8ded59

Apply discovered config paths lazily Summary: # Problem Statement The previous diff discovers and persists each service’s effective config path, but config loading, diffing, committing, and rollback still use fixed paths. The CLI can therefore update a file other than the one consumed by the service. `ConfigSession` also eagerly initializes the Agent domain. This makes BGP-only operations depend on a running Agent and unnecessarily materializes Agent session state. Existing staged configs and revision-only diffs should not need to contact either service. # Solution Make session initialization service-independent and load each config domain only when an operation first needs its live configuration. On first use, resolve that service’s current path, validate write access, and establish its Git baseline. Use the discovered path consistently for live diffs, permission checks, transactional commits, and rollbacks. Continue to use existing staged files without service discovery and use session metadata as the common history anchor for Agent and BGP commits. Limit path discovery and service actions to domains that actually changed. This allows BGP-only operations to proceed without querying Agent state and prevents unrelated domains from being materialized. Reviewed By: srikrishnagopu Differential Revision: D121518641 fbshipit-source-id: b852d45b4c30ee99fad1b83721735b8ed86baf2f

Add persistent service lifecycle commands Summary: # Problem Statement `run_test.py` starts FBOSS services only as part of running a test. This makes it difficult to leave a working FBOSS environment running for manual `fboss2` CLI testing. # Solution Add `services start` and `services stop` commands. Users may select `agent`, `qsfp`, or `fsdb`; omitting the list selects all services. Require configs only for selected services, validate binaries before startup, materialize the agent config, verify service readiness, and roll back selected services on failure. Treat `agent` as the multi-switch HW/SW agent pair and use production-compatible systemd names required by `fboss2` config operations. Update HW-agent cleanup to disable the unit name being replaced, avoiding collisions with packaged unit symlinks. Reviewed By: Scott8440 Differential Revision: D121664200 fbshipit-source-id: a9b74a27cc161be4b6b88bd82b8cf5e81cabf4b2

Generate agent configs from platform ASIC configs Summary: Add `fboss2 config gen agent` to assemble `agent.conf` from a platform generated ASIC config. Resolve platforms across vendor directories, select default or named profiles from `asic_config.json`, and load key-value, JSON, or YAML ASIC config formats. Keep the lookup and generation helpers reusable for future agent config sections. Reviewed By: daiwei1983 Differential Revision: D118068053 fbshipit-source-id: 44c2a9072a9aab85e73f2a4d69fcb10cfa10b494

Materialize test configs with linked SDK versions Summary: OSS hardware tests currently consume generated agent configs containing placeholder or absent `sw.sdkVersion` values, while the actual linked SDK versions are known only through the packaged `npu_sdk_metadata.json`. Extend the shared `npu_sdk_utils.py` library to validate per-binary SDK metadata and materialize an agent config with the exact `asicSdk` and `saiSdk` values before starting tests or agent services. Teach `fboss_test_runner` to select the SDK-owning executable for each SAI test mode. Split-agent runs use `fboss_hw_agent-sai_impl`; monolithic tests, link tests, and SAI benchmarks use their directly linked executable. Retain generated configs under `/opt/fboss/logs/run_test/generated_configs/<runner-type>/<source-config-name>`, atomically replacing the prior config for the same runner and source. This preserves the exact runtime config for debugging and includes configs created during `--log-bundle` runs in the resulting bundle. Missing or invalid metadata fails during runner setup instead of launching with incorrect placeholders. PASSED : 160 FAILED : 0 SKIPPED : 0 TIMEOUT : 0 Test output stored at: hwtest_results_2026_Sep_14-04_38_46_PM.csv ``` Double checked the generated config which has the correct sdkVersion like we did for Netcastle ``` [root@fboss338826521.ash6 /opt/fboss]# jq -r '.sw.sdkVersion' /opt/fboss/logs/run_test/generated_configs/fboss2_integration/agent.conf { "asicSdk": "6.5.32", "saiSdk": "13.3.0.0_odp" } ``` Reviewed By: AarjunC Differential Revision: D119893710 fbshipit-source-id: efda99864956a43c69d111dbce3ac134fded55a0

Run ASIC config validation as buck tests Summary: `asic_config_v3` validation only ran as a hand-invoked script (`validation/validate_asic_configs.py`), so nothing caught a schema violation or a stale checked-in config until someone remembered to run it. This converts it into two `python_unittest` targets under `test/` so the checks run on-diff, while keeping both runnable directly as `python3 -m ...` for the OSS flow that has no buck. - `validate_asic_configs_schemas` validates the platform, per-ASIC, and vendor-common JSON against the schemas in `schemas/`. - `validate_asic_configs_contents` generates each platform variant and compares it against its checked-in internal reference, reporting BYTE_MATCH / SEMANTIC_MATCH / CONTENT_MISMATCH and flagging stale generated files. Supporting changes: - Move `discover_platforms` from `gen.py` to `paths.py` so the tests can discover platforms without depending on the generator binary. - Extract `resolve_variant_config` out of `BaseAsicConfigGenerator.__init__` into a module-level helper in `base_generator.py`. Generator behavior is unchanged; the tests now resolve a variant's effective config through the same merge logic instead of duplicating it. - Resolve materialized references generically. Previously a hardcoded `{("wedge800bact", "hw_test"): ...}` table decided which variants compare against a materialized agent config instead of a synced ASIC config, so every future HW-test platform would need a manual entry. Reference selection is now keyed off the variant's effective `config_gen_type`, deriving `oss/hw_test_configs/<platform>.agent.materialized_JSON`. Any platform that declares a `HW_TEST` variant is picked up with no change to the test. - Point the OSS docs at the new module paths. Platforms: 7 Variants: 10 BYTE_MATCH: 8 SEMANTIC_MATCH: 2 CONTENT_MISMATCH: 0 ok ---------------------------------------------------------------------- Ran 3 tests in 1.776s OK ``` ``` > buck2 run //fboss/lib/asic_config_v3/test:validate_asic_configs_schemas test_asic_config_schemas (fboss.lib.asic_config_v3.test.validate_asic_configs_schemas.TestValidateAsicConfigV3Schemas) ... Vendor common configs (vendor_common.schema.json): asic_vendors/broadcom/xgs/sai_common.json: PASSED asic_vendors/broadcom/xgs/sdk_common.json: PASSED OCP SAI common config (vendor_common.schema.json): asic_vendors/common/ocp_sai_common.json: PASSED Broadcom XGS ASIC configs (broadcom_xgs_asic_config.schema.json): asic_vendors/broadcom/xgs/asics/tomahawk5.json: PASSED asic_vendors/broadcom/xgs/asics/tomahawk6.json: PASSED Platform configs (platform_config.schema.json): platforms/accton/wedge800bact/asic_config/asic_config.json: PASSED platforms/arista/icecube800banw/asic_config/asic_config.json: PASSED platforms/celestica/icecube800bc/asic_config/asic_config.json: PASSED platforms/celestica/icetea800bc/asic_config/asic_config.json: PASSED platforms/celestica/ladakh800bcls/asic_config/asic_config.json: PASSED platforms/celestica/montblanc/asic_config/asic_config.json: PASSED platforms/celestica/tahan800bc/asic_config/asic_config.json: PASSED 12 passed, 0 failed ok ---------------------------------------------------------------------- Ran 1 test in 0.012s OK ``` ## OSS Setup a docker container on devserver using the test plan of D117743767 ``` [root@devvm33541 fboss]# ./fboss/lib/asic_config_v3/validate-contents-helper.sh ASIC config v3 comparison results: Platform Variant Reference Result -------------- ------------ --------------------------------------------------------------------- -------------- icecube800banw <default> lib/asic_config_v2/synced_asic_configs/icecube800banw.yml BYTE_MATCH icecube800bc <default> lib/asic_config_v2/synced_asic_configs/icecube800bc.yml BYTE_MATCH icetea800bc <default> lib/asic_config_v2/synced_asic_configs/icetea800bc.yml BYTE_MATCH ladakh800bcls rack lib/asic_config_v2/synced_asic_configs/ladakh800bcls_rack.yml BYTE_MATCH ladakh800bcls test_fixture lib/asic_config_v2/synced_asic_configs/ladakh800bcls_test_fixture.yml BYTE_MATCH montblanc <default> lib/asic_config_v2/synced_asic_configs/montblanc.yml BYTE_MATCH tahan800bc chassis lib/asic_config_v2/synced_asic_configs/tahan800bc_chassis.yml BYTE_MATCH tahan800bc test_fixture lib/asic_config_v2/synced_asic_configs/tahan800bc_test_fixture.yml BYTE_MATCH wedge800bact <default> lib/asic_config_v2/synced_asic_configs/wedge800bact.yml SEMANTIC_MATCH wedge800bact hw_test oss/hw_test_configs/wedge800bact.agent.materialized_JSON SEMANTIC_MATCH Platforms: 7 Variants: 10 BYTE_MATCH: 8 SEMANTIC_MATCH: 2 CONTENT_MISMATCH: 0 ok ---------------------------------------------------------------------- Ran 1 test in 1.490s OK Configs have been written to specified output directory ``` Reviewed By: tanmayaudupa Differential Revision: D117609005 fbshipit-source-id: 725b231838c1fb8e1cebd555d3b283d8f2ca359a