fix(seaweedfs): restore S3 TLS and COSI provisioner SA after 4.31 bump - #2916

Code Review

This pull request updates the SeaweedFS package Makefile to apply two new patches: s3-tls-main-port.patch and cosi-provisioner-sa-name.patch. It also introduces a new test suite (s3_tls_cosi_sa_test.yaml) to verify S3 TLS behavior on the main port and ensure the COSI provisioner deployment correctly uses the service-account-name-based ServiceAccount. I have no feedback to provide as the changes are well-implemented and include appropriate tests.

Actionable comments posted: 1

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/system/seaweedfs/patches/cosi-provisioner-sa-name.patch`:
- Around line 9-10: The patch removes the seaweedfs.componentName helper
function which provides critical default fallback behavior for
serviceAccountName. When global.seaweedfs.serviceAccountName is unset or empty,
the resulting name becomes invalid, preventing pod scheduling. Restore the use
of the seaweedfs.componentName helper function in the serviceAccountName
assignment on line 10 while still incorporating the value-driven naming from
global.seaweedfs.serviceAccountName, ensuring the chart's defaulting contract is
preserved.

LGTM — both regressions are real, the patches are minimal and consistent with the chart's existing naming, and the new helm-unittest coverage fails without the fix.

Business context: The SeaweedFS 4.31 chart bump broke E2E on main for every PR (seaweedfs-system never becomes ready); this restores S3 TLS on the main port and fixes the COSI provisioner ServiceAccount reference so the release reconciles again.

Verified the mechanism end to end:

• S3 TLS — with enableSecurity: true + httpsPort: 0 the pre-4.31 logic rendered -cert.file/-key.file on the main port; 4.31 gated them behind if .Values.s3.httpsPort, so s3 served plaintext while the readiness/liveness probes hit s3.port with scheme: HTTPS. Moving the tlsArgs include out of the httpsPort gate (still under enableSecurity) restores TLS on the main port; -port.https stays gated on httpsPort.
• COSI SA — cosi-service-account.yaml and the ClusterRoleBinding subject both name the SA {{ .Values.global.seaweedfs.serviceAccountName }}-objectstorage-provisioner (raw value, no default), while the Deployment referenced seaweedfs.componentName (release-based). With serviceAccountName != release name the Deployment pointed at a non-existent SA. The patch aligns the Deployment with the SA object and the binding.
• The new tests are non-vacuous: reverting both rendered templates to the base version fails both cases (-key.file missing; serviceAccountName renders seaweedfs-objectstorage-provisioner instead of the value-based name).

On the inline bot suggestion (cosi-provisioner-sa-name.patch): switching the Deployment to include "seaweedfs.serviceAccountName" . is not correct here. That helper defaults to "seaweedfs", but the SA object and the ClusterRoleBinding subject use the raw .Values.global.seaweedfs.serviceAccountName with no default. Routing only the Deployment through the helper would re-introduce a mismatch whenever serviceAccountName is empty (Deployment -> seaweedfs-..., SA object -> -...). The raw-value form is the consistent fix.

Non-blocking follow-ups

1. Both are upstream chart issues (httpsPort-gated TLS args; Deployment using componentName while the SA and binding use the value). Worth an upstream PR so these vendored patches can eventually drop — the downstream copies are a fine interim.