BugFix: install iperf3 source build dependencies

[v-kchintakin]

Description

Fixes Iperf3 source installation failures when a C compiler is not already installed.

Iperf3 declared Git and Make as dependencies, but it overrode the public install() method. This bypassed Tool.install(), which is responsible for loading declared tool dependencies before calling the tool-specific installation implementation.

When the package-manager installation was unavailable or an installed Iperf3 version needed to be replaced, LISA attempted to build Iperf3 from source. The build then failed during ./configure because no C compiler was available.

This change:

• Renames Iperf3.install() to Iperf3._install() so installation runs through the inherited Tool.install() workflow.
• Adds Gcc as a direct Iperf3 dependency alongside Git and Make.
• Preserves the existing Iperf3 version detection and source-build behavior.
• Adds a regression test verifying that all three dependencies are requested before Iperf3._install() is called.

Gcc is declared directly rather than relying on Make to load it transitively. If Make is already installed or cached, its installation method may not run, so its dependencies are not guaranteed to be processed.

Related Issue

Type of Change

• Bug fix
• New feature
• Breaking change
• Refactoring
• Documentation update

Checklist

• Description is filled in above
• No credentials, secrets, or internal details are included
• Peer review requested
• Tests executed and results posted below

Test Validation

Completed locally:

• python -m unittest selftests.test_iperf3 -v — passed
• Runtime check that Iperf3.install is Tool.install — passed
• Runtime check that dependencies are [Git, Make, Gcc] — passed
• Black check on changed files — passed
• Flake8 check on changed files — passed
• Python compilation of changed files — passed
• git diff --check — passed

[Copilot]

Pull request overview

This PR fixes Iperf3 source-installation failures by restoring the intended Tool.install() workflow so declared dependencies are installed before the tool-specific install logic runs (including adding Gcc as an explicit dependency for source builds).

Changes:

• Rename Iperf3.install() to Iperf3._install() so dependency loading is handled by the inherited Tool.install() implementation.
• Add Gcc to Iperf3.dependencies alongside Git and Make.
• Add a unit test to validate dependency-loading behavior during Iperf3.install().

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
selftests/test_iperf3.py	Adds a regression unit test around Iperf3.install() dependency loading.
lisa/tools/iperf3.py	Routes installation through Tool.install() and adds Gcc as a declared dependency.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[v-kchintakin]

@microsoft-github-policy-service agree company="Microsoft"

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (1)

lisa/tools/iperf3.py:154

• Minor: Avoid catching broad Exception here. Posix.install_packages() failures are raised as LisaException (and subclasses like RepoNotExistException / ReleaseEndOfLifeException), so catching Exception can hide programming errors and make unexpected failures harder to diagnose. Catch LisaException (or a narrower subset) instead, and let other exception types surface.

    def _install(self) -> bool:
        posix_os: Posix = cast(Posix, self.node.os)
        try:
            posix_os.install_packages("iperf3")
        except Exception as e:

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[v-kchintakin]

MagicMock(spec=CBLMariner) passes isinstance(mock, CBLMariner) because a specced mock exposes the spec class through class. I verified this behavior directly, and the focused unit test passes successfully. Therefore, no change is required here.

[LiliDeng]

Please double check mariner3 and mariner4, the package names may be different.

[v-kchintakin]

Thanks for pointing this out. I double-checked the Azure Linux 3.0 and 4.0 package specs, and both versions use binutils and glibc-devel. These package names are also used by the existing CBLMariner paths in LISA tools such as Netperf and NTTTCP. The Dom0 validation successfully installed both packages and completed the Iperf3 source build, so no version-specific package mapping is needed.