Antrea

Currently Antrea uses a third-party tool called [bincover](https://github.com/confluentinc/bincover) to measure code coverage when running end-to-end (e2e) tests. This tool has been deprecated in favor of the built-in Go coverage profiling tool (https://go.dev/testing/coverage/) starting with Go 1.20, and it is no longer maintained. We would like to remove usage of bincover from the Antrea project and start using the built-in Go tool. Expected Outcome: Complete removal of the bincove dependency. Code coverage can still be measured with the same accuracy when running Antrea e2e tests and the results can still be reported to [Codecov](https://about.codecov.io/).

As a K8s network plugin (CNI plugin), Antrea provides networking functions for K8s Pods. These Pods are located on different Nodes, which can be in different availability zones, or even different geos. We would like to provide as part of Antrea (built-in capability) a tool to monitor Pod connectivity across the cluster. This tool should be able to report the average network latency between any 2 Nodes in the cluster. The latency information could then be visualized using a heatmap representation in the Antrea web UI. Expected Outcome: A new Antrea API which reports network health information and latency between K8s Nodes. If time allows, the Antrea web UI should also be extended so that latency information can be easily visualized through a heatmap.

Currently Antrea can be installed using a K8s YAML manifest or through the provided Helm chart. We believe there is value in providing a 3rd installation method, using the "antctl" CLI. The CLI installation / upgrade method would have the following advantages: a) more user-friendly, with support for command-line options to customize the installation, b) ability to run sanity checks on the K8s cluster before comitting to the installation, c) when upgrading, the CLI will ensure that Antrea components are upgraded in the optimal order, to minimize workload disruption. Expected Outcome: A new command for antctl, the Antrea CLI, which will provide support for installation and upgrade.

Antrea currently relies on Github's Dependabot to automatically updated dependencies (Go modules / Github Actions) on the main branch. There is a key limitation with Dependabot, which is that it doesn't support automatically updating dependencies with security vulnerabilities in "active" release branches (for Antrea minor versions which are currently actively supported). This limitation means that maintainers have to manually backport Dependabot patches when they address security vulnerabilities, which has become a burden. Renovate (https://docs.renovatebot.com/) is an alternative tool for dependency management, and it seems that it offers richer configuration options and may not suffer from the same limitation as Dependabot. Expected Outcome: Migrate the Dependabot config to a Renovate config for the main Antrea repository (antrea-io/antrea), as well as for all other repositories (under the antrea-io organization) which currently use Dependabot. Dependencies that are currently updated as a group (e.g., golang.org/x modules) should remain that way. The Renovate config should include provisions to automatically perform security updates in active release branches. The change should not impact developer workflows and the Antrea release cycle; all experiments should be performed in a fork.

Antrea's PacketCapture feature (https://github.com/antrea-io/antrea/blob/main/docs/packetcapture-guide.md) includes custom BPF code generation for packet filters defined in the PacketCapture CRD. The code is currently tested using manually-generated test cases, which is tedious, error-prone, and limits testing coverage. Given that the code attempts to mimic the BPF generation done by tcpdump, we should improve the testing approach by: 1) using AI to generate comprehensive test inputs, 2) using tcpdump to generate reference BPF code for the inputs, 3) comparing our generated BPF with the tcpdump reference, 4) analyzing any differences to determine if our BPF is incorrect or equivalent, 5) updating our BPF generation to match tcpdump when possible, and 6) committing all test cases to run in CI. Expected Outcome: A comprehensive test suite for the PacketCapture BPF generation code that uses tcpdump-generated BPF as a reference. The test suite should be integrated into CI and should increase testing coverage compared to the current manually-generated test cases. Any discrepancies between Antrea's BPF generation and tcpdump's should be analyzed and resolved, with the BPF generation code updated as needed to match tcpdump's output when appropriate.