* fix(bp-seaweedfs): vendor upstream chart, drop fromToml-using template (#340)
The upstream seaweedfs/seaweedfs 4.22.0 chart now ships
templates/shared/security-configmap.yaml which calls fromToml — a Sprig
function added in Helm 3.13. Flux v1.x helm-controller bundles a Helm
SDK older than 3.13 and PARSES every template before any
{{- if .Values.global.seaweedfs.enableSecurity }} gate fires, so the file's
mere presence breaks install on every Sovereign with:
parse error at (bp-seaweedfs/charts/seaweedfs/templates/shared/security-configmap.yaml:21):
function "fromToml" not defined
even though enableSecurity defaults to false. Setting the gate value
does NOT skip parsing — only deleting / never-shipping the file does.
Fix shape (per ticket #340):
1. Vendor upstream seaweedfs/seaweedfs 4.22.0 into chart/charts/seaweedfs/
(committed bytes, not auto-pulled at build time). Required because the
upstream Helm repo overwrites 4.22.0 in place — re-pulling would
re-introduce the broken file.
2. Delete charts/seaweedfs/templates/shared/security-configmap.yaml.
Every other template that references the deleted ConfigMap is gated
under {{- if enableSecurity }} so removing it is a no-op for our
default deployment shape (Catalyst SeaweedFS auth happens at the S3
layer via IAM creds from External Secrets, not via the upstream
chart's TLS/JWT machinery).
3. Drop the dependencies: block from chart/Chart.yaml; add
annotations.catalyst.openova.io/no-upstream=true so the
blueprint-release workflow's hollow-chart guard (issue #181) skips
the auto-pull/round-trip checks for this chart.
4. Whitelist platform/seaweedfs/chart/charts/ in .gitignore so the
vendored bytes are tracked.
5. Bump bp-seaweedfs 1.0.1 → 1.1.0 (signal: vendored, not auto-pulled).
6. Add tests/no-fromtoml.sh — chart-test that asserts the offending
file stays deleted across future re-vendors. Runs in
.github/workflows/blueprint-release.yaml as a publish-gating check.
Unblocks Phase-8a observability + storage chain on otech (bp-loki,
bp-mimir, bp-tempo, bp-velero, bp-harbor, bp-grafana all dependsOn
bp-seaweedfs).
Closes#340
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(scripts): align expected-bootstrap-deps.yaml with bp-harbor's actual deps
The bp-harbor HR at clusters/_template/bootstrap-kit/19-harbor.yaml lines
35-37 already removed `bp-seaweedfs` from its dependsOn (cloud-direct
architecture per ADR-0001 §13 — Harbor writes blobs directly to cloud
Object Storage on Sovereigns, not via SeaweedFS), but the expected DAG
in scripts/expected-bootstrap-deps.yaml was never updated to match.
Pre-existing drift on main; surfaced by the dependency-graph-audit
check on PR #504 (bp-seaweedfs vendoring fix). Fixing it inline so the
audit passes on the same PR — the two changes are both about the
storage chain on Sovereigns.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: alierenbaysal <alierenbaysal@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1865ac8975