Skip to content

[gNMI] Migrate legacy tests to native managed gRPC suites #26384

Description

@hdwhdw

Problem

The legacy tests/gnmi setup stops supervisor-managed programs and launches the
gNMI server through nohup with test-specific flags. Nine test modules depend
on that lifecycle (27 test functions, roughly 67 static cases, and 55 legacy
helper call sites). It is fragile under setup failures, certificate changes,
reboots, and teardown, and it couples management-plane tests to PTF/DUT CLI
clients and text parsing.

The repository now has a better destination:

We should move directly to that native end state rather than deepen another
PTF-side adapter.

Target architecture

Use segregated behavior suites over one shared managed gRPC test environment:

  • tests/gnmi_native/: native pygnmi behavior tests;
  • tests/gnoi/: typed sonic_grpc.GnoiClient behavior tests;
  • tests/common/: the only owner of PKI, CONFIG_DB profiles, target selection,
    supervisor restart, authenticated readiness, rollback/cleanup, and post-reboot
    re-provisioning.

Suite-local fixtures may select profiles or expose domain names, but must not
duplicate server lifecycle. Native tests assert structured values and gRPC
status codes, not legacy CLI text.

Use expand-contract: land native coverage beside old tests, prove parity, then
delete each corresponding old slice. Do not mix native branches into the old
helper, and do not leave a permanent parallel smoke suite.

Review and test policy

Each PR must be one coherent, independently green reviewer story, normally
about 200-500 hand-written changed lines. Avoid drive-by cleanup, unrelated
conditional marks, and generated protocol code mixed with migration changes.

For every applicable PR:

  1. Run static/unit tests.
  2. Run each changed integration test individually on local vms-kvm-t0.
  3. Run the changed module in one invocation to expose lifecycle interactions.
  4. Run the changed native subset three consecutive times from restored state.
  5. Run old/new parity tests when replacing behavior.
  6. Require JUnit zero failures/errors.
  7. Require no unhandled thread/process exception, leaked process, core dump,
    failed critical process, stale certificate/config row, or forced recovery
    caused by the new tests.

Every PR description should include exact commands, JUnit summary, warnings,
and before/after DUT service health. KVM is the default development gate;
multi-ASIC, management-VRF, SmartSwitch, CRL IPv6, and release compatibility
also require their specialized matrix before deleting old coverage.

Current KVM evidence

Validated on a local virtual T0 testbed:

  • Existing managed gNOI System.Time: TLS and UDS passed (2 tests).
  • Legacy native CONFIG_DB incremental Set oracle passed.
  • #26013 capabilities and OpenConfig Get passed individually.
  • Full #26013 pygnmi module passed 14/14; JUnit reported zero
    failures/errors.
  • Five subscription cases emitted unhandled background-thread exceptions during
    teardown (CANCELLED: Channel closed or INVALID_ARGUMENT: queue: disposed).
    This is a blocking quality gap despite the green JUnit result.

Phased plan

Phase 1 / PR 1: stabilize native pygnmi client

  • Resolve the open review issues in Add native pygnmi MgmtGnmic client and migrate gNMI tests #26013: supported Python syntax, exact DUT
    binding, typed errors, fork-safe channel lifetime, and clean subscription
    cancellation.
  • Gate: capabilities/Get/STREAM/POLL/ONCE/early-close pass three full KVM runs
    with no unhandled thread warnings.

Phase 2 / PR 2: establish one shared managed environment

Phase 3 / PR 3: create tests/gnmi_native read-only tracer

  • Add capabilities, one OpenConfig Get, and one namespaced SONiC DB Get.
  • Gate: same selected DUT supplies RPC and expected data; three KVM passes.

Phase 4 / PR 4: port native CONFIG_DB Set tracer

  • Port one complete update/Get/restore flow using direct pygnmi values.
  • Add one invalid-path negative assertion.
  • Gate: old/new state transition parity and three KVM passes.

Phase 5 / PR 5: port remaining ordinary writes

  • Port full replace, ordinary authorization-sensitive writes, APPL_DB JSON, and
    latency coverage.
  • Keep SmartSwitch protobuf behavior separate.
  • Gate: documented old/new parity and three full-module KVM passes.

Phase 6 / PR 6: port Get and subscription matrix

  • Port COUNTERS_DB Get plus POLL, STREAM SAMPLE, ON_CHANGE, and ONCE.
  • Gate: clean close on count, timeout, sync, and early break; no thread warnings;
    three KVM passes.

Phase 7 / PR 7: port certificate authorization and CRL

  • Add explicit valid, unregistered, unauthorized, and revoked client profiles.
  • Assert native gRPC status codes.
  • Gate: deterministic IPv4/IPv6-aware CRL lifecycle, no stale process/cert/role
    state, KVM plus required IPv6 validation.

Phase 8 / PR 8: port VRF profiles

  • Express default and management VRF as environment profiles.
  • Gate: Set/Get/Subscribe parity and complete SNMP/VRF restoration; specialized
    management-VRF validation before deleting old tests.

Phase 9 / PR 9: port rotation and 2038 certificates

  • Add managed certificate rotation and custom validity periods.
  • Gate: feature disable/enable rotation and after-2038 RPC pass three KVM runs
    with no stale cert state.

Phase 10 / PR 10: port SmartSwitch behavior

  • Use pygnmi proto_bytes for DPU APPL_DB writes and typed gNOI routing metadata.
  • Gate: offline request construction plus SmartSwitch target proof; retain old
    coverage until specialized parity passes.

Phase 11 / PR 11: consolidate native gNOI suite

  • Land tests/gnoi/ on the same common environment; do not fork TLS setup.
  • Gate: System.Time/File.Stat pass three KVM runs; reboot re-provisioning passes;
    upgrade remains image-pair gated.

Phase 12 / PR 12: contract legacy setup

  • Remove migrated helpers/modules, manual server nohup lifecycle, obsolete
    certificate plumbing, and stale skips.
  • Gate: full native KVM matrix passes three times, specialized matrices pass,
    search confirms the targeted legacy path is gone, and nightly soak shows no
    teardown/critical-process regression.

Compatibility decision

The managed legacy telemetry launcher disables native write. We should either
declare a modern gnmi-native compatibility floor for the new suite or fund a
separate product-image change. Do not silently claim telemetry-only native-write
parity.

Non-goals

  • Preserve legacy CLI output or helper signatures.
  • Migrate copied nohup paths in HA, DASH, SAI validation, or other suites in
    these PRs.
  • Delete old behavior based only on new smoke coverage.

Metadata

Metadata

Assignees

Type

No type

Projects

Status
Backlog

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions