Skip to content

vm-update: maszyna na szablon z aplikacji; alarm zawieszonej wysyłki - #36

Merged
mbeczynski merged 2 commits into
mainfrom
feat/vm-update
Oct 28, 2026
Merged

mbeczynski merged 2 commits into
mainfrom
feat/vm-update

Conversation

@mbeczynski

Copy link
Copy Markdown
Contributor

Co

  • cloudmachine-agent vm-update — Lima osadza pliki szablonu w ~/.lima/<maszyna>/lima.yaml przy tworzeniu i startuje z tej kopii, więc nowy szablon z wydania nigdy nie trafiał do istniejącej maszyny (komentarz w cmsmb.yaml twierdził inaczej - poprawiony). vm-update: odmawia w trakcie kopii TM, bez vm.env, i gdy szablon zmienia dysk/CPU/pamięć/typ VM; podmienia kopię (stara zostaje jako lima.yaml.before-<data>), dwa restarty (pierwszy przepisuje jednostki, drugi je uruchamia), sprawdza usługi. Te same kroki przeniosły żywą cmsmb 27.10.
  • vm-status: Template: this app's / OLDER than this app's - run: cloudmachine-agent vm-update.
  • Zawieszona wysyłka: pasma w toku i od 15 min żadnej udanej wysyłki (log rclone) → vm-status (kod 1) i backup-health (upload-stalled). Log bez żadnej wysyłki nie alarmuje (nowa maszyna).
  • VMLayout.start: limactl start --timeout 50m jak w vm-setup. vm/README: sekcja „Updating the machine”, pierwszy rozruch „do ~30 min”.

Testy

  • swift test: 309 zielonych, swift-format lint --strict czysto.
  • Jednorazowa cmtest z szablonu wydania 1.3.17 (pierwszy rozruch tym razem 1 min): vm-status = OLDER → vm-update 30 s, usługi aktywne, kopia lima.yaml.before-*, Template: this app's; drugie wywołanie = „already runs”.
  • Zawieszona wysyłka: plik 3 GB, w trakcie wysyłki iptables DROP na 443 → po 16 min vm-status HANGS (rc 1), backup-health „The upload to Google Drive hangs”; po zdjęciu blokady wysyłka wróciła sama w 80 s, alarm zgasł.
  • Żywa cmsmb (tylko odczyt): Template: OLDER (zmieniony komentarz szablonu) - po wdrożeniu do przeniesienia vm-update w przerwie między kopiami.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AU1MhxJW1e9oTB2XvjX8WT

mbeczynski and others added 2 commits October 28, 2026 08:42
… hanging upload

Lima embeds the template's files into ~/.lima/<machine>/lima.yaml when the
machine is created and boots from that copy, so a newer template never
reached an existing machine (the template's comment said otherwise).
vm-update replaces the copy (keeping the old one next to it) and restarts
twice: the first boot rewrites the units, the second runs them. It refuses
during a backup, on a machine without vm.env, and when the template would
change the disk, CPU or memory. vm-status says when the machine's template
is older than the app's. The steps moved the live cmsmb on 27.10.2026.

A cut network left eight uploads "in progress" for 47 min with no error
line. Bands in progress and none uploaded for 15 min is now reported by
vm-status and backup-health (upload-stalled). limactl start waits 50 min,
as vm-setup does.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AU1MhxJW1e9oTB2XvjX8WT
…" 30 min

Tried on a throwaway machine on 28.10.2026: with the network dropped mid-upload
the alarm came after 16 min, and the upload resumed by itself 80 s after the
network was back - the message says so, restart only as the fallback. The same
template's first boot took 1 min that morning, 30 min the day before.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AU1MhxJW1e9oTB2XvjX8WT
@mbeczynski
mbeczynski merged commit f61ad31 into main Oct 28, 2026
2 checks passed
@mbeczynski
mbeczynski deleted the feat/vm-update branch October 28, 2026 08:30
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