* feat: Implement iperf3 exporter core logic and log level configuration
This commit completes the core functionality of the iperf3 exporter and adds flexible log level configuration.
Key changes:
- Added command-line (`--log-level`) and environment variable (`LOG_LEVEL`) options to configure the logging level.
- Implemented the main test orchestration loop (`main_loop`) which:
- Discovers iperf3 server pods via the Kubernetes API.
- Periodically runs iperf3 tests (TCP/UDP) between the exporter pod and discovered server pods.
- Avoids self-testing.
- Uses configurable test intervals, server ports, and protocols.
- Requires `SOURCE_NODE_NAME` to be set.
- Refined the `parse_and_publish_metrics` function to:
- Accurately parse iperf3 results for bandwidth, jitter, packets, and lost packets.
- Set `IPERF_TEST_SUCCESS` metric (0 for failure, 1 for success).
- Zero out all relevant metrics for a given path upon test failure to prevent stale data.
- Handle UDP-specific metrics correctly, zeroing them for TCP tests.
- Improved robustness in accessing iperf3 result attributes.
- Updated the main execution block to initialize logging, start the Prometheus HTTP server, and invoke the main loop.
- Added comprehensive docstrings and inline comments throughout `exporter/exporter.py` for improved readability and maintainability.
These changes align the exporter's implementation with the details specified in the design document (docs/DESIGN.MD).
* feat: Update Helm chart and CI for exporter enhancements
This commit introduces updates to the Helm chart to support log level
configuration for the iperf3 exporter, and modifies the CI workflow
to improve image tagging for pull requests.
Helm Chart Changes (`charts/iperf3-monitor`):
- Added `exporter.logLevel` to `values.yaml` (default: "INFO") to allow
you to set the exporter's log level.
- Updated `templates/exporter-deployment.yaml` to use the
`exporter.logLevel` value to set the `LOG_LEVEL` environment
variable in the exporter container.
CI Workflow Changes (`.github/workflows/ci.yaml`):
- Modified the Docker image build process to tag images built from
pull requests with `pr-<PR_NUMBER>`.
- Ensured that these PR-specific images are pushed to the container
registry.
- Preserved existing tagging mechanisms (e.g., SHA-based tags).
* fix: Add Docker login and permissions to CI workflow
This commit fixes the Docker image push failure in the CI workflow
by adding the necessary Docker login step and ensuring the correct
permissions are set for the GITHUB_TOKEN.
- Added a Docker login step using `docker/login-action@v3` to the
`Build Docker Image` job in `.github/workflows/ci.yaml`. This
authenticates to GHCR before attempting to push images.
- Added a `permissions` block to the `Build Docker Image` job, granting
`packages: write` scope to the `GITHUB_TOKEN`. This is required
to allow pushing packages to the GitHub Container Registry.
---------
Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
The default service account name was empty, causing issues when
rbac.create was disabled. This commit sets a reasonable default.
Also, add a comprehensive design document.
* feat: Add support for arm64 architecture
This commit introduces support for the arm64 architecture by:
1. **Updating the Dockerfile:**
* The `exporter/Dockerfile` now uses the `TARGETARCH` build argument to dynamically determine the correct path for `libiperf.so.0`. This allows the same Dockerfile to be used for building both `amd64` and `arm64` images.
2. **Modifying GitHub Workflows:**
* The CI workflow (`.github/workflows/ci.yaml`) and the Release workflow (`.github/workflows/release.yml`) have been updated to build and push multi-architecture Docker images (`linux/amd64` and `linux/arm64`).
* This involves adding the `docker/setup-qemu-action` for cross-compilation and specifying the target platforms in the `docker/build-push-action`.
3. **Helm Chart:**
* No changes were required for the Helm chart as the image tag will now point to a multi-arch manifest, and the default iperf3 server image (`networkstatic/iperf3:latest`) is assumed to be multi-arch. Node selectors in the chart are not architecture-specific.
These changes enable the deployment of the iperf3-monitor on Kubernetes clusters with arm64 nodes.
* fix: Ensure multi-platform builds with Docker Buildx
This commit updates the GitHub Actions workflows to correctly set up
Docker Buildx for multi-platform (amd64, arm64) image builds.
Previously, the workflows were missing the `docker/setup-buildx-action`
step, which led to errors when attempting multi-platform builds as the
default Docker driver does not support this.
The following changes were made:
1. **Added `docker/setup-buildx-action@v3`:**
- This step is now included in both the CI (`.github/workflows/ci.yaml`) and Release (`.github/workflows/release.yml`) workflows before the QEMU setup and build/push actions.
2. **Dockerfile (`exporter/Dockerfile`):**
- Remains as per the previous commit, using `TARGETARCH` to correctly copy architecture-specific libraries. This part was already correct for multi-arch builds.
3. **Helm Chart:**
- No changes were required for the Helm chart.
This ensures that the CI/CD pipeline can successfully build and push
Docker images for both `linux/amd64` and `linux/arm64` architectures.
* fix: Correct Dockerfile lib path and add Helm dependency toggle
This commit includes two main changes:
1. **Fix Dockerfile library path for amd64:**
- I updated the `exporter/Dockerfile` to correctly determine the source path for `libiperf.so.0` when building for different architectures.
- Specifically, for `TARGETARCH=amd64`, the path `/usr/lib/x86_64-linux-gnu/libiperf.so.0` is now used.
- For `TARGETARCH=arm64`, the path `/usr/lib/aarch64-linux-gnu/libiperf.so.0` is used.
- I achieved this by copying the library to a canonical temporary location in the builder stage based on `TARGETARCH`, and then copying it from this location into the final image. This resolves an issue where builds for `amd64` would fail to find the library.
2. **Add Helm chart option to disable dependencies:**
- I added a new option `dependencies.install` (default: `true`) to `charts/iperf3-monitor/values.yaml`.
- This allows you to disable the installation of managed dependencies (i.e., Prometheus Operator via `kube-prometheus-stack` or `prometheus-operator` from TrueCharts) even if `serviceMonitor.enabled` is true.
- I updated the `condition` for these dependencies in `charts/iperf3-monitor/Chart.yaml` to `dependencies.install, serviceMonitor.enabled, ...`.
- This is useful for you if you manage your Prometheus Operator installation separately.
---------
Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
Removes the outdated markdown files and fixes the .gitignore to ignore packaged chart files in the correct directories. This prevents them from being committed to
Fixes an issue where truecharts prometheus operator version and
repository values where not accessible because they were not under the
`dependencies` scope.
This commit introduces a configurable dependency for the Prometheus Operator,
allowing you to choose between the standard kube-prometheus-stack and
the TrueCharts version of prometheus-operator.
Changes include:
1. **values.yaml:**
* Added a `dependencies` section with the following new values:
* `useTrueChartsPrometheusOperator` (boolean, default: false):
Controls which operator dependency is enabled.
* `trueChartsPrometheusOperatorRepository` (string, default:
"oci://tccr.io/truecharts"): Repository for the TrueCharts operator.
* `trueChartsPrometheusOperatorVersion` (string, default: "8.11.1"):
Chart version for the TrueCharts operator.
2. **Chart.yaml:**
* The `kube-prometheus-stack` dependency condition is updated to
`"serviceMonitor.enabled, !values.dependencies.useTrueChartsPrometheusOperator"`.
* A new dependency for `prometheus-operator` (TrueCharts) is added:
* `name: prometheus-operator`
* `version: "{{ .Values.dependencies.trueChartsPrometheusOperatorVersion }}"`
* `repository: "{{ .Values.dependencies.trueChartsPrometheusOperatorRepository }}"`
* `condition: "serviceMonitor.enabled, values.dependencies.useTrueChartsPrometheusOperator"`
This provides you with more flexibility in choosing your Prometheus
Operator stack while using the iperf3-monitor chart.
Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
This commit implements a verified yq command syntax in the
`.github/workflows/release.yml` file to ensure correct and reliable
updating of Chart.yaml version and appVersion from Git tags.
The previous attempts faced issues with yq argument parsing and
environment variable substitution. The new commands:
VERSION=$VERSION yq e -i '.version = strenv(VERSION)' ./charts/iperf3-monitor/Chart.yaml
VERSION=$VERSION yq e -i '.appVersion = strenv(VERSION)' ./charts/iperf3-monitor/Chart.yaml
were tested and confirmed to correctly modify
the Chart.yaml file as intended.
This change should resolve the issues where chart versions were being
set incorrectly or to empty strings during the release process.
This commit addresses several issues to improve repository accuracy and CI reliability:
1. **README.md Updates:**
* I corrected the Helm repository URL to `https://malarinv.github.io/iperf3-monitor/`.
* I updated the default exporter image name to `ghcr.io/malarinv/iperf3-monitor` in examples.
* I revised the License section to accurately reflect the AGPLv3 license present in the `LICENSE` file, removing contradictory statements.
2. **License Consistency:**
* I confirmed `LICENSE` file contains AGPLv3. README now correctly refers to it.
3. **Helm Chart Adjustments:**
* `charts/iperf3-monitor/Chart.yaml`: I removed placeholder comments for clarity. Versioning is handled by the release workflow.
* `charts/iperf3-monitor/values.yaml`: I updated `exporter.image.repository` to `ghcr.io/malarinv/iperf3-monitor` to match the CI build image name.
4. **CI Workflow Verification:**
* I verified that `.github/workflows/release.yml` correctly uses `yq` to set chart versions from Git tags and publishes to the correct GitHub Pages URL. This should prevent the previously noted `chart.metadata.version is required` error, which was associated with an older version of the release workflow.
These changes ensure that the documentation is up-to-date, the Helm chart defaults are correct, and the CI pipeline for chart publishing is robust.
This involved addressing several Helm linting issues I identified in the iperf3-monitor chart.
Here's what I changed:
- I corrected a syntax error (an unexpected backslash) in the label value within `charts/iperf3-monitor/templates/exporter-deployment.yaml`.
- I resolved a missing dependency by:
- Adding the `prometheus-community` Helm repository.
- Updating the dependency name in `Chart.yaml` to `kube-prometheus-stack` when a repository URL is specified.
- Running `helm dependency update` to fetch the `kube-prometheus-stack` dependency.
- I fixed YAML parsing errors in `charts/iperf3-monitor/templates/exporter-deployment.yaml` caused by incorrect newline handling in the Helm helper templates (`charts/iperf3-monitor/templates/_helpers.tpl`). This involved:
- Ensuring the `iperf3-monitor.selectorLabels` helper template output ends with a newline.
- Adjusting whitespace control in the `iperf3-monitor.labels` helper template to preserve newlines between label entries.
- I restored the `app.kubernetes.io/component: exporter` label to the top-level metadata in `charts/iperf3-monitor/templates/exporter-deployment.yaml`.
After these modifications, `helm lint charts/iperf3-monitor` passes without any errors or warnings.
Configure automated checks for pull requests including:
- Linting the Helm chart.
- Building the exporter Docker image.
- A placeholder for future tests.
Add core components for continuous cluster network validation:
- Python exporter (`exporter/`) to run iperf3 tests and expose Prometheus metrics.
- Helm chart (`charts/iperf3-monitor/`) for deploying the exporter as a
Deployment and iperf3 server as a DaemonSet.
- CI/CD workflow (`.github/workflows/release.yml`) for building/publishing
images and charts on tag creation.
- Initial documentation, license, and `.gitignore`.