Add CsonicHost for docker-exec based neighbor access in cSONiC testbeds

[securely1g]

Description

cSONiC (docker-sonic-vs) neighbor containers run as Docker containers on the VM host — they have no SSH daemon, no admin user, and no management IP. This makes the existing SonicHost class (which requires Ansible/SSH connectivity) unusable for cSONiC neighbors.

This PR adds CsonicHost, a lightweight host class that executes commands via docker exec (subprocess) instead of SSH, providing the same command()/shell() interface that tests expect from neighbor hosts.

Motivation

When running sonic-mgmt tests with --neighbor_type sonic on a cSONiC testbed, the nbrhosts fixture fails at setup because SonicHost.__init__() tries to SSH into each neighbor and gather facts. With --neighbor_type csonic, tests can now access cSONiC neighbors without SSH infrastructure.

Changes

• tests/common/devices/csonic.py (new): CsonicHost class with:

  • command() / shell() — run commands via docker exec, returns Ansible-compatible dict (stdout, stdout_lines, rc, etc.)
  • shutdown() / no_shutdown() — interface up/down via ip link set
  • get_route() — query FRR routing table via vtysh
  • get_port_channel_status() — query teamd state
  • config() — configure FRR via vtysh
  • Supports both local and remote (SSH-tunneled) Docker hosts

• tests/conftest.py:

  • Add csonic to --neighbor_type choices
  • Create CsonicHost instances in nbrhosts fixture using container naming convention csonic_{group-name}_{vm_name}
  • Include csonic in techsupport collection check

• tests/vlan/test_vlan_ping.py:

  • Handle cSONiC interface naming (PortChannel1 instead of po1, Ethernet0 instead of eth1) when --neighbor_type csonic

Usage

# Run tests against cSONiC testbed
pytest --neighbor_type csonic --testbed vms-kvm-t0-csonic ...

Test Results

Tested on cSONiC KVM testbed (T0 topology, 4 docker-sonic-vs neighbors with PortChannels):

Test	Result
vlan/test_vlan_ping	✅ PASSED
bgp/test_bgp_fact	✅ PASSED
bgp/test_frr_config_check	✅ PASSED
crm/test_crm_next_hop_group	✅ PASSED
lldp/test_lldp	✅ PASSED

Related PRs

• sonic-mgmt cSONiC: move BGP config from FRR templates to CONFIG_DB #22680 — CONFIG_DB BGP config + PortChannel support for cSONiC neighbors
• sonic-buildimage #25764 — Add bgpcfgd + lldpd to docker-sonic-vs

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[securely1g]

Hi @wangxin @hdwhdw — would appreciate your review on this PR.

@wangxin A few questions for you:

1. Reuse SonicHost vs separate CsonicHost: Do you think it would be better to extend SonicHost to support cSONiC containers (e.g., with a docker_exec transport mode) rather than introducing a new CsonicHost class? The reason I went with a separate class is that SonicHost.__init__() does heavy lifting at init time (SSH connection, _gather_facts(), _get_os_version(), get_running_config_facts(), etc.) that all assumes Ansible/SSH connectivity. cSONiC containers have no SSH daemon, no admin user, and no management IP — they're Docker containers accessed via docker exec. That said, if you prefer consolidating into SonicHost with a transport abstraction, I'm happy to refactor.

2. Scope: CsonicHost is intended only for neighbor devices in cSONiC testbeds, not as a DUT host. The DUT is still a full SONiC VS VM managed by SonicHost. The cSONiC neighbors are lightweight docker-sonic-vs containers that only need basic command execution (get MAC, check interfaces, etc.).

3. Unit tests: Is there a unit test framework for the tests/common/ folder (especially tests/common/devices/)? I'd like to add tests for CsonicHost if there's an existing pattern to follow.

@hdwhdw — since you've been working on the cSONiC testbed infrastructure, would love your thoughts on this approach as well.