Repository navigation
seaweedfs: tenant replicationFactor never reaches the master #4241
Description
replicationFactor on a SeaweedFS tenant never reaches the master. The extra chart writes it to one key and the master reads another.
packages/extra/seaweedfs/templates/seaweedfs.yaml:232 (Simple) and :234 (MultiZone) emit master.defaultReplicaPlacement. The master is rendered from master.defaultReplication instead, at packages/system/seaweedfs/charts/seaweedfs/templates/master/master-statefulset.yaml:134:
-defaultReplication={{ .Values.master.defaultReplication }} \
Nothing in the chart reads master.defaultReplicaPlacement, so the master always starts with the defaultReplication pinned in packages/system/seaweedfs/values.yaml, currently 001, whatever the tenant set.
The filer side is fine. seaweedfs.yaml:327,329 emit filer.defaultReplicaPlacement and charts/seaweedfs/templates/filer/filer-statefulset.yaml:172 reads that key. Filer and master disagree as soon as replicationFactor is not 2.
Invisible on defaults, because replicationFactor: 2 renders 001, which is what the system chart pins anyway.
Effect: replicationFactor: 1 still gets two copies of every volume, and each logical volume still costs a slot on both volume servers. On a small install that halves how many buckets fit before the master starts answering Not enough data nodes found.
Not patching it yet, needs a call on whether to rename the emitted key or make the master template accept both.
Activity
lexfrei commentedon Sep 15, 2026
The same dead key has a second consequence on MultiZone, with a different radius, which is worth recording here rather than separately.
packages/extra/seaweedfs/templates/seaweedfs.yamlcomputes the cross-datacenter placement for MultiZone as"{{ sub .Values.replicationFactor 1 }}00"and writes it tomaster.defaultReplicaPlacement, which the master never reads. What it does read ismaster.defaultReplication, and that is"001"from the data-plane chart's own values (packages/system/seaweedfs/values.yaml:44on main as of today, though the key is the durable anchor rather than the line). So the master's default stays"001"regardless of topology, and an assign that arrives without an explicit replication is placed within one rack instead of across zones. Aweed shellgrow and any direct client assign take that path.Ordinary S3 traffic is unaffected, and that is why this stays invisible: the filer supplies a placement on every request from
filer.defaultReplicaPlacement, which is a live key and does followreplicationFactor. So the zone spread a MultiZone instance is configured for holds for everything that goes through the filer, and silently does not for anything that does not.lexfrei commentedon Sep 16, 2026
The filer block further down emits the same
defaultReplicaPlacementkey, andpackages/system/seaweedfs/charts/seaweedfs/templates/filer/filer-statefulset.yaml:172does read it (theglobal.seaweedfs.enableReplicationbranch above it renders the false arm by default), soreplicationFactoris not dropped everywhere: it reaches the filer, which sends it on every assign, and the master parses the filer's string at the same call that would have parsed its own default. That call drops a fourth character without an error, so anything abovereplicationFactor: 10arrives as a truncated placement and nothing reports it, which is #4294. Whichever way this one is fixed, renaming the emitted key or teaching the master template to accept both, it opens a second path into that parser, so a bound on the field belongs with the fix.