Skip to content

feat: auto-size game memory settings from the container memory limit - #68

Merged
ValgulNecron merged 3 commits into
mainfrom
feat/config-auto-memory-limit
Jul 5, 2026
Merged

ValgulNecron merged 3 commits into
mainfrom
feat/config-auto-memory-limit

Conversation

@ValgulNecron

Copy link
Copy Markdown
Collaborator

What

Game servers now use the RAM they're given. A configSchema field may declare autoFromMemoryLimit: {percent}; when the user leaves the field empty, the operator computes percent% of the game container's effective memory limit (GameServer override or template default) and injects it as the field's value — rendered as whole mebibytes (8Gi × 75% → 6144M). Resizing a server recomputes the value and rolls the pod (it participates in the config hash).

Precedence is unchanged: explicit spec.config value > schema default > auto-computed > unset.

  • CRD: ConfigField.autoFromMemoryLimit (+ regenerated deepcopy/CRD YAML/chart CRDs). Plain Min/Max markers only — no CEL in the unbounded configSchema array (apiserver cost budget).
  • Reconciler: materializeConfig computes the value; new shared effectiveResources helper replaces the two hand-rolled copies in the game/agent container builders.
  • Web: type mirror + an "Auto: N% of the memory limit" placeholder on empty auto-sized wizard fields.
  • Module: submodule bumped to minecraft-java 2.7.0 (ValgulNecron/gameplane-module#8) — MAX_MEMORY/INIT_MEMORY drop their static 2G/1G defaults for 75% auto-sizing; gameplaneMinVersion: 0.2.0-beta.6 keeps older operators from pruning the field into itzg's 1G fallback.

Why

The old static 2G heap default was disconnected from the memory slider: an 8Gi server wasted 6Gi, and a hand-set heap at/above the limit got OOM-killed (the cgroup limit caps memory but never sizes the heap).

Tests

  • materializeConfig unit cases: computed value, explicit override wins, schema default wins, template-resources fallback, no-limit stays unset, hash tracks the limit.
  • envtest: StatefulSet env gets MAX_MEMORY=6144M from an 8Gi limit; explicit INIT_MEMORY survives.
  • e2e: minecraft bot test pins its own heap env, unaffected.

Note: helm upgrade never updates CRDs — existing clusters need kubectl apply of the regenerated CRD YAML (kind CI clusters are recreated per job).

🤖 Generated with Claude Code

A ConfigField may declare autoFromMemoryLimit: {percent}; when neither
spec.config nor the schema default provides a value, materializeConfig
computes percent% of the game container's effective memory limit,
rendered as whole mebibytes (8Gi at 75% -> 6144M). The computed value
flows through env, configFiles values, and the config hash, so resizing
a server rolls the pod with a matching heap. Explicit values and schema
defaults still win; no memory limit leaves the field unset.

Also extracts the effectiveResources helper the game and agent
container builders were both hand-rolling.

Signed-off-by: valgulnecron <39313199+ValgulNecron@users.noreply.github.com>
Mirrors autoFromMemoryLimit into the template types and shows an
"Auto: N% of the memory limit" placeholder on empty auto-sized fields
so users know leaving them blank is the right move.

Signed-off-by: valgulnecron <39313199+ValgulNecron@users.noreply.github.com>
Points the submodule at gameplane-module#8: MAX_MEMORY/INIT_MEMORY now
declare autoFromMemoryLimit: {percent: 75} instead of static 2G/1G
defaults, with gameplaneMinVersion 0.2.0-beta.6 gating older operators.

Signed-off-by: valgulnecron <39313199+ValgulNecron@users.noreply.github.com>
@ValgulNecron
ValgulNecron merged commit 220c514 into main Jul 5, 2026
20 checks passed
@ValgulNecron
ValgulNecron deleted the feat/config-auto-memory-limit branch July 5, 2026 12:18
@ValgulNecron
ValgulNecron restored the feat/config-auto-memory-limit branch July 5, 2026 12:30
@ValgulNecron
ValgulNecron deleted the feat/config-auto-memory-limit branch July 5, 2026 21:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant