New deployments get two tags attached (e.g. "t5" and "zombie_pentagon")
so operators can filter the Komodo deployment list by game and by map.
Tags are ensured via read/ListTags + write/CreateTag fallback, then
attached with write/UpdateTagsOnResource against the deployment name.
Tag application runs fire-and-forget after CreateDeployment: any failure
logs a warning and the server creation proceeds. Tags are cosmetic
organization inside Komodo, not a correctness requirement.
execute/DestroyDeployment queues the container removal and returns before
it actually completes. write/DeleteDeployment refuses while a container
still exists for the deployment, so the entity survived every teardown.
Poll komodoInspectHealthy between the two calls until it stops reporting
a running container (up to 30s), then delete the entity.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
PLUTAINER_PORT sets the port the container listens on, so the mapping
should be <port>:<port>, not <port>:28960 — otherwise the container is
bound to a port nothing inside is listening on.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Full server lifecycle management from Electric Cherry: pick game/mode/map/pluto
key in the Fleet page, EC provisions the deployment via Komodo, allocates a
port in 28960-28980, creates the 0o777 host dir, and starts the container.
Destroy button tears everything down (Komodo Destroy+Delete, rm -rf host dir,
transactional DB cleanup) and surfaces any partial-failure warnings inline.
Same phase cuts over to the new naming scheme (t5_zombie_cosmodrome_1 etc.).
Komodo entity names now match EC server names 1:1 (no more _/- transform), and
the map catalog carries friendly/slug/canonical for each of the 11 t5 zombie
maps. Server rows gain game_mode, map_slug, host_dir, config_file, game_id,
image, created_by, and destroyed_at columns for provisioning + audit.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
josh
