jklein
485f4fa52b
game.seasonalEvents was handed to the container unchanged, into the image's DISABLESEASONALEVENTS. Its default true therefore wrote DISABLESEASONALEVENTS=true: the seasonal events were OFF in every install this chart has ever produced, while values.schema.json described the very same key as "true means events are enabled" (#215). Of the two ways out, this is the loud one. Inverting the template under the old key would have flipped the behaviour of every existing release in silence - the same class of mistake that created the issue. Renaming the key cannot be missed: game.seasonalEvents no longer exists, additionalProperties is false on the game block, and a values file that still carries it fails schema validation on upgrade instead of quietly meaning the opposite. The new key is positive (enableSeasonalEvents) to avoid a double negative, so the chart negates it on the way into the env var. Go's "not" cannot do that: it reads every non-empty string as true, and the schema deliberately accepts the string form of booleans, so "false" would have flipped the wrong way. The helper compares explicitly and fails on anything that is neither true nor false rather than filing it under "off". The default is enableSeasonalEvents: false, which renders the DISABLESEASONALEVENTS this chart has always rendered. At chart defaults the 6.1.0 and 7.0.0 manifests are identical, so upgrading alone moves no server; switching the events on is now a deliberate act with a key that means it. Separate finding from the same issue, fixed here because it lives in the block being touched: "--set game=null" - or a leftover "game:" whose sub-keys were deleted - aborted the render with a nil pointer at .Values.game.maxPlayers. The game block never got the null-safe treatment of #99 that probes, security contexts and resources have. It now falls back to the documented defaults, and the schema accepts the null accordingly. The same gap remains in the dev and server blocks; it is reported, not fixed here. Major bump: a values key is removed, and the schema rejects it.
137 lines
5.2 KiB
YAML
137 lines
5.2 KiB
YAML
# Scale the whole chart down without uninstalling it: scaleDown: true renders
|
|
# every Deployment/StatefulSet with replicas: 0 (and suspends CronJobs) and
|
|
# takes precedence over any per-workload replicas value. PVCs, Secrets and
|
|
# Services stay in place; scaleDown: false brings the workloads back up.
|
|
scaleDown: false
|
|
|
|
dev:
|
|
debug: false
|
|
|
|
game:
|
|
experimental: false
|
|
maxPlayers: 4
|
|
# Seasonal (holiday) events. The image only knows the negative switch
|
|
# DISABLESEASONALEVENTS, so the chart NEGATES this value on the way in:
|
|
# enableSeasonalEvents: true renders DISABLESEASONALEVENTS="false" (events
|
|
# run), false renders "true" (events off). Only true/false are accepted, in
|
|
# boolean or string form; anything else aborts the render instead of being
|
|
# read as one of the two.
|
|
#
|
|
# The default is false on purpose, and it is not a preference: it reproduces
|
|
# what this chart has ALWAYS rendered. Up to 6.1.0 the key was called
|
|
# game.seasonalEvents and was passed through UNCHANGED, so its default true
|
|
# wrote DISABLESEASONALEVENTS=true — the events were off in every install,
|
|
# while values.schema.json claimed "true means events are enabled" (#215).
|
|
# Keeping the rendered result identical is what makes this rename loud
|
|
# instead of silent: nobody's server changes behaviour by upgrading, and the
|
|
# old key is now rejected by the schema, so anyone who set it has to decide
|
|
# again. Set enableSeasonalEvents: true to actually switch the events on.
|
|
enableSeasonalEvents: false
|
|
|
|
server:
|
|
# Replica count for this workload; 0 is allowed and scales it down.
|
|
# The chart-global scaleDown flag takes precedence.
|
|
replicas: 1
|
|
gamePort: 30777
|
|
messagingPort: 30888
|
|
storage: 20Gi
|
|
resources:
|
|
# Limits are optional: memory and ephemeral-storage limits default to
|
|
# limitFactor x the request, an explicitly set limit always wins, and a
|
|
# CPU limit is only set when configured explicitly under "limits".
|
|
# The game server holds a large world in memory, so the default factor
|
|
# stays at 2 to keep the limit at the previously published 8Gi.
|
|
limitFactor: 2
|
|
requests:
|
|
memory: "4Gi"
|
|
cpu: "1"
|
|
ephemeral-storage: "5Gi"
|
|
|
|
# Extra environment variables for the server container, appended to the ones
|
|
# the chart always sets (DEBUG, MAXPLAYERS, PGID, PUID, SKIPUPDATE, STEAMBETA,
|
|
# DISABLESEASONALEVENTS, SERVERGAMEPORT, SERVERMESSAGINGPORT). Values are
|
|
# rendered through tpl and support the value, secretKeyRef and configMapKeyRef
|
|
# forms:
|
|
# - name: SOME_ENV
|
|
# value: "{{ .Release.Name }}"
|
|
# - name: FROM_SECRET
|
|
# valueFrom:
|
|
# secretKeyRef:
|
|
# name: "some-secret"
|
|
# key: "someKey"
|
|
# - name: FROM_CONFIGMAP
|
|
# valueFrom:
|
|
# configMapKeyRef:
|
|
# name: "some-configmap"
|
|
# key: "someKey"
|
|
env: []
|
|
|
|
# The image's healthcheck script queries the server's HTTPS API on the game
|
|
# port (SERVERGAMEPORT), so liveness/startup keep working under port overrides.
|
|
livenessProbe:
|
|
exec:
|
|
command:
|
|
- "/bin/sh"
|
|
- "-c"
|
|
- "/home/steam/healthcheck.sh"
|
|
failureThreshold: 4
|
|
successThreshold: 1
|
|
periodSeconds: 30
|
|
timeoutSeconds: 10
|
|
readinessProbe:
|
|
tcpSocket:
|
|
port: api
|
|
periodSeconds: 10
|
|
timeoutSeconds: 5
|
|
failureThreshold: 3
|
|
# The startup probe gates liveness/readiness. The server downloads / updates
|
|
# the game files via Steam on startup, which can take a long time:
|
|
# budget 30s * 40 = 20 minutes.
|
|
startupProbe:
|
|
exec:
|
|
command:
|
|
- "/bin/sh"
|
|
- "-c"
|
|
- "/home/steam/healthcheck.sh"
|
|
periodSeconds: 30
|
|
timeoutSeconds: 10
|
|
failureThreshold: 40
|
|
|
|
securityContext:
|
|
pod:
|
|
runAsNonRoot: true
|
|
# The wolveix/satisfactory-server image supports rootless operation only
|
|
# as its built-in "steam" user (uid/gid 1000) - the entrypoint rejects any
|
|
# other non-root uid/gid. The PUID/PGID env vars only apply to the root
|
|
# entrypoint path and are ignored when running non-root.
|
|
runAsUser: 1000
|
|
runAsGroup: 1000
|
|
# fsGroup keeps the data volume writable for the steam user.
|
|
# OnRootMismatch (instead of Always) skips the recursive chown/chmod of
|
|
# the multi-GB game files on every pod start; volumes provisioned by chart
|
|
# versions < 4.0.0 were already chowned to 1000:1000 by the image's root
|
|
# entrypoint.
|
|
fsGroup: 1000
|
|
fsGroupChangePolicy: OnRootMismatch
|
|
# RuntimeDefault applies the container runtime's default seccomp filter,
|
|
# which blocks the syscalls a normal workload never makes. It sits in the
|
|
# pod context on purpose: from here it covers every container in the pod
|
|
# including init containers, while a container-level seccompProfile would
|
|
# have to be repeated for each one (and silently missed on the next one
|
|
# added). A container that genuinely needs a different filter can still
|
|
# override it under securityContext.container, which wins over this value.
|
|
seccompProfile:
|
|
type: RuntimeDefault
|
|
container:
|
|
allowPrivilegeEscalation: false
|
|
# Works because the chart mounts emptyDirs at /tmp and the steam user's
|
|
# ~/.steam, ~/.config and ~/.local (steamcmd bootstraps itself into
|
|
# ~/.local/share/Steam on start); all other writes go to the PVC at
|
|
# /config.
|
|
readOnlyRootFilesystem: true
|
|
runAsNonRoot: true
|
|
capabilities:
|
|
drop:
|
|
- ALL
|
|
add: []
|