Repository navigation
seaweedfs: enabling it on the root tenant without ingress hangs on a missing ingress-nginx-system #5204
Description
Describe the bug
Setting spec.seaweedfs: true on the root Tenant while spec.ingress is false hangs. hr/seaweedfs-system stays Ready=False with unable to get 'tenant-root/ingress-nginx-system' dependency: helmreleases.helm.toolkit.fluxcd.io "ingress-nginx-system" not found, and hr/seaweedfs and hr/tenant-root sit in Running 'upgrade' action until their timeouts (10 and 15 minutes). Nothing says that ingress is needed. The platform backup bucket depends on seaweedfs, so backups do not work either and all other HelmReleases are Ready.
The root tenant _namespace values are hardcoded. packages/system/cozystack-basics/templates/cozystack-values-secret.yaml writes etcd: tenant-root and ingress: tenant-root whatever the Tenant says (same cause as #4783 for etcd). packages/extra/seaweedfs/templates/seaweedfs.yaml (line 203) adds dependsOn: ingress-nginx-system when _namespace.ingress equals the release namespace, and nothing deploys that HelmRelease when spec.ingress is false. The e2e install patches ingress: true together with seaweedfs: true (hack/e2e-install-cozystack.bats, line 280), so the requirement is there but not written anywhere.
Environment
Cozystack v1.7.0, variant isp-full, fresh install with the root Tenant patched only with host.
To reproduce
kubectl patch tenants.apps.cozystack.io root -n tenant-root --type merge -p '{"spec":{"seaweedfs":true}}'
kubectl -n tenant-root get hrActual behaviour
seaweedfs-system is False with the missing dependency, seaweedfs and tenant-root stay Unknown and after the timeout the upgrade fails. Adding "ingress":true to the Tenant (and a host) unblocks it, everything came up within about 5 minutes.
Expected behaviour
seaweedfs-system does not depend on an ingress that is not deployed, or the Tenant says clearly that seaweedfs needs ingress on the root tenant.
Activity
dosubot commentedon Nov 4, 2026
One additional detail: removing the
dependsOnentry alone would not make this an ingress-free deployment. The system chart defaults S3 ingress toenabled: true, and the app chart supplies its ingress class, hostname and TLS settings without disabling it. So an ingress-free path would also need to address S3 exposure, not just the Flux dependency. [1] [2]Also, validation should distinguish “no ingress available” from
spec.ingress: false: child tenants can inherit an ancestor’s ingress with that flag false. The existing dependency condition deliberately skips inherited ingress becauseingress-nginx-systemdoes not exist locally in those tenants. [3] [4]To reply, just mention @dosu.
Docs are dead. Just use Dosu.