80b84afb1e5586511b792e75dbcba674dc657bfe
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 IgorandClaude Opus 5
|
4bcdf6907c |
fix: stop and start an instance from the instance's own menu
1.3.0 put suspend and resume in the main menu and on the command line, which
meant remembering a separate command and picking the instance separately for
each of the two. They belong where you are already looking at the instance.
The menu of one instance now ends with a single line above "Back", worded for the
state that instance is in when the menu is drawn:
Instance 2 - supa2.didgibot.com - running
...
Suspend it (stop it, keep its data)
Instance 2 - supa2.didgibot.com - suspended
...
Resume it (start it again with its data)
The state is read again every time the menu is drawn, so right after suspending
an instance the same line reads "Resume it". The instance's state is in the menu
title, and the instance picker names it next to every instance, so you can see
which ones are awake before choosing one.
- The main menu's two entries "Suspend instance" and "Resume instance" are gone.
"Show instance" is now "Show instance (and suspend or resume it)": one way in.
- Asking for the tunnel command of a sleeping instance says it is suspended and
to resume it from this menu, instead of printing a command that cannot work.
- The line printed after suspending, and the one `supaspin list` prints under a
sleeping instance, point at the menu line rather than at a command.
`supaspin suspend N` and `supaspin resume N` still work for scripting.
Verified on instance 2 (supa2.didgibot.com): suspended from the instance menu,
the menu came back reading "Resume it" and the picker showed "(suspended)",
resumed from the same line, 12/12 pods with 0 restarts and its 55 tables and
11 MB of data intact.
Tests: 136 pass (6 new). Version 1.3.0 -> 1.3.1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
IgorandClaude Opus 5
|
2e4e46c878 |
feat: suspend and resume an instance without losing its data
An instance you are not using had to be deleted, and deleting it destroys its database. Now it can be put to sleep instead. sudo supaspin suspend N # stops all twelve pods, keeps everything else sudo supaspin resume N # starts them again with the same data Suspending gives the server back, per instance: the 1.875 GiB it had reserved and the 1.5-2.5 GiB it was actually using, its twelve pod slots out of the 110 a node allows, and its two server ports (Postgres 544N, Studio 300N). It keeps: the database and the uploads (the disk images stay mounted), the .env file with its passwords and keys, the HTTPS certificate, which goes on renewing itself while the instance sleeps, and the hostname, which answers "service unavailable" until the instance is resumed. Disk space is not given back - that is the data being kept. How: every service takes its pod count from a `replicaCount` setting, so suspend writes zero into all twelve and re-applies the chart, resume writes one. This goes through the instance's stored settings rather than scaling the running pods by hand, so it survives anything that re-applies the chart later. `supaspin upgrade` now understands a sleeping instance: it stores the new memory limits for it and leaves it asleep instead of waiting for pods that by design do not exist. `supaspin list` reports each instance as running, suspended or partly suspended, and prints no tunnel commands for a sleeping one, because nothing is listening on its ports. `suspend` and `resume` take one instance number and have no "all" form: stopping every instance is not something to type by accident, and resuming them all at once would start 36 pods in one go. Reading the stored settings and handing them back to Helm is now shared by upgrade, suspend and resume. Verified on instance 2 (supa2.didgibot.com): suspended to zero pods, memory reserved on the node fell from 25766 MiB to 23846 MiB (exactly the 1920 MiB it had), ports 3002 and 5442 freed, then resumed to 12/12 pods with 0 restarts, its 55 tables and 11 MB of data intact and the gateway answering again. Tests: 130 pass (17 new). Version 1.2.1 -> 1.3.0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
IgorandClaude Opus 5
|
99fdf7a0ab |
fix: write the repository's real address in the docs
The repository is owned by the organisation `public`, not by the user `igor`. Gitea forwards the old address for anything a browser or git does, so the install command and the clone lines kept working and the wrong address went unnoticed. An API call is the exception. A POST to `/api/v1/repos/igor/supaspin/...` is answered with a redirect that curl does not follow for a POST, so the command returns an empty body and no error - which reads as a rejected token. Creating the v1.2.0 tag and opening its pull request both failed this way first. - CLAUDE.md: the tagging rule now names `public` and says why an API address cannot use the forwarded one. - README.md, install.sh: the install, token and clone commands now use the address the server actually serves. Version 1.2.0 -> 1.2.1. No change to what the program does. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
IgorandClaude Opus 5
|
1d49234400 |
feat: raise the memory ceilings and add supaspin upgrade
The two logging services were being killed by the kernel in a loop on instance 1 (supa1.didgibot.com): vector 297 times, analytics 36 times, both exit code 137 (out of memory). The old ceilings sat right on top of what the services normally use, so any backlog crossed them. Measured across the three running instances on 2026-09-22: - analytics 612 / 694 / 662 MiB against a 768 MiB ceiling -> 1536 MiB - vector 287 / 290 MiB against 512 MiB -> 1024 MiB - realtime 269 / 287 / 300 MiB against 384 MiB -> 768 MiB - kong 260 / 269 / 265 MiB against 512 MiB -> 768 MiB - studio 203, storage 187, rest 162 MiB against 256 MiB -> 512 MiB - db 163 / 175 / 273 MiB against 2048 MiB -> unchanged Limits only. The requests stay at 128 MiB (512 for db): the server is one machine shared with the production workloads and already has 80% of its memory reserved, so raising the requests would leave production nothing to schedule into. Raising a limit reserves nothing - it only moves the point at which the kernel kills. Per-instance totals go from 5.875 GiB to 9.5 GiB of limit; reserved memory is unchanged at 1.875 GiB. New numbers only reach instances created afterwards, so this also adds `sudo supaspin upgrade [N]`: it reads back the values Helm stored at install time, replaces the memory block in them and applies the chart again. Pods are replaced service by service; databases, uploads, certificates and .env files are untouched. Without a number it does every instance and reports which ones failed. Also available from the menu. Fixes a rollout that could never finish, found by the first upgrade: Studio binds port 3001 (3002, 3003) on the server itself so it can be reached over an SSH tunnel, and one port can be held by one pod at a time. The default rollout starts the replacement pod before stopping the old one, so the replacement never got the port and stayed Pending for ever. The Studio deployment now stops the old pod first. Postgres was never affected: a StatefulSet already replaces its pod that way. The values file that carries the instance's secrets and the post-renderer arguments are now built by shared helpers used by both create and upgrade. Tests: 113 pass (12 new). Version 1.1.2 -> 1.2.0 in VERSION, the VERSION constant and README. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |