Feature: Node-übergreifender Auto-Update-Scheduler für VM/CT (eigenes System, Modal mit Zeit pro Node) #174

Closed
opened 2026-06-23 21:00:56 +00:00 by chinux · 0 comments
Owner

Ziel

Ein eigenes, node-uebergreifendes Auto-Update-System fuer VM/CT-Updates — getrennt vom bestehenden Scheduler (ScheduledJob), mit eigenem Modell, Modal und Tick. Zentrales Konfig-Modal zeigt alle Nodes; pro Node eine eigene Zeit definierbar.

Abgrenzung / Wiederverwendung (WICHTIG)

Eigenes System (eigenes Model/Router/Modal), ABER bewusst die vorhandene, bewaehrte Mechanik nutzen statt neu zu erfinden:

  • Cron-Tick: im bestehenden Scheduler-Loop (server/scheduler.py, laeuft 1x/Minute, croniter==3.0.0 vorhanden) eine eigene Tick-Funktion _auto_update_tick() ergaenzen — KEIN zweiter Background-Loop.
  • Ausfuehrung: den kanonischen Bulk-Update-Pfad bulk-job verwenden (update_router.py _run_bulk_job/_bulk_jobs, start_bulk_job) — NICHT eine eigene Update-Logik bauen. (Bezug #123: ein einziger Update-Pfad.)
  • Begruendung fuers "eigene System": semantisch sauberer (Auto-Update ist Policy pro Node, nicht ein Einzel-Job), eigenes Modal, eigene Statusanzeige — ohne den generischen Scheduler zu ueberladen.

Datenmodell — neue Tabelle node_auto_update (eine Zeile pro Node)

  • node_name (PK/unique)
  • enabled (bool)
  • frequency enum: daily | weekly
  • weekday (0-6, nur bei weekly)
  • time_hhmm (z. B. "03:00") — pro Node eigene Zeit
  • scope enum: all (alle VMs+CTs) | security (nur Security-Updates) ← Auswahl 3
  • vmid_filter JSONB: optionale Liste einzelner VMIDs/CTs (leer = ganze Node) ← Auswahl 4 (einzelne waehlbar)
  • reboot_policy: fix notify_only (kein Auto-Reboot; Reboot-Notwendigkeit nur melden)
  • last_run_at, last_status, last_summary (JSONB: pro VM ok/fail/reboot_required)
  • intern: time_hhmm+frequency+weekday → Cron-Expression ableiten (fuer den Tick).

Tick-Logik (_auto_update_tick)

  1. 1x/Minute: alle enabled Node-Configs lesen, deren naechster Lauf faellig ist.
  2. Pro faellige Node: Kandidaten ermitteln — VMs und CTs mit verfuegbaren Updates (CT==VM gleich behandeln), gefiltert nach scope (all/security) und vmid_filter.
  3. Lauf ueber bulk-job starten (programmatisch, nicht via HTTP).
  4. Reboot: nie automatisch. Wenn nach Update reboot_required → in last_summary markieren + notify()-Event auto_update_reboot_required (node + betroffene VMs).
  5. Ergebnis in last_run_at/status/summary; notify-Event auto_update_done (ok/fail-Counts).

Frontend — uebergreifendes Modal "Auto-Update planen"

  • Einstieg: globaler Button (z. B. im Task-/Dashboard-Header), oeffnet ein Modal mit Tabelle aller Nodes.
  • Pro Node-Zeile editierbar: An/Aus, Frequenz (Daily/Weekly als simple Auswahl), bei Weekly Wochentag, Uhrzeit (HH:MM), Scope (Alle / nur Security), optional VM/CT-Auswahl (Aufklappen → Checkboxen je VM/CT der Node).
  • Anzeige: naechster Lauf, letzter Lauf + Status (ok/fail/Reboot-noetig-Badge).
  • Bewusst einfach verstaendlich: Daily/Weekly + Uhrzeit, KEIN roher Cron im UI (Cron wird intern abgeleitet).

Backend-Router auto_update_router.py

  • GET /auto-update (alle Node-Configs + Nodes ohne Config als "aus")
  • PUT /auto-update/{node_name} (config setzen/aktualisieren)
  • POST /auto-update/{node_name}/run-now (sofort ausloesen, gleicher Pfad wie Tick)
  • alle mit require_role("operator") + check_node_scope (Mandanten!) — pro Node-Config darf nur, wer die Node im Scope hat.

Akzeptanz

  • Modal listet alle (scope-sichtbaren) Nodes; pro Node eigene Frequenz/Uhrzeit/Scope speicherbar.
  • Faelliger Lauf aktualisiert VMs und CTs der Node gemaess Scope/Filter via bulk-job.
  • Reboot wird nie automatisch ausgefuehrt, aber gemeldet (notify + Summary-Badge).
  • Tick laeuft im bestehenden Scheduler-Loop (kein zweiter Loop).
  • Cross-Tenant: man kann nur Nodes im eigenen Scope konfigurieren/ausloesen.

Bezug

#123 (kanonischer bulk-job-Pfad — Voraussetzung/Wiederverwendung), Scheduler (scheduler.py, croniter), #108 (Tenant-Scope-Muster fuer den Router), notify-Pipeline.

Branch

feat/node-auto-update-scheduler

## Ziel Ein **eigenes, node-uebergreifendes Auto-Update-System** fuer VM/CT-Updates — getrennt vom bestehenden Scheduler (`ScheduledJob`), mit eigenem Modell, Modal und Tick. Zentrales Konfig-**Modal** zeigt **alle Nodes**; **pro Node eine eigene Zeit** definierbar. ## Abgrenzung / Wiederverwendung (WICHTIG) Eigenes System (eigenes Model/Router/Modal), ABER **bewusst** die vorhandene, bewaehrte Mechanik nutzen statt neu zu erfinden: - **Cron-Tick:** im bestehenden Scheduler-Loop (`server/scheduler.py`, laeuft 1x/Minute, `croniter==3.0.0` vorhanden) eine **eigene Tick-Funktion** `_auto_update_tick()` ergaenzen — KEIN zweiter Background-Loop. - **Ausfuehrung:** den **kanonischen Bulk-Update-Pfad** `bulk-job` verwenden (`update_router.py` `_run_bulk_job`/`_bulk_jobs`, `start_bulk_job`) — NICHT eine eigene Update-Logik bauen. (Bezug #123: ein einziger Update-Pfad.) - Begruendung fuers "eigene System": semantisch sauberer (Auto-Update ist Policy pro Node, nicht ein Einzel-Job), eigenes Modal, eigene Statusanzeige — ohne den generischen Scheduler zu ueberladen. ## Datenmodell — neue Tabelle `node_auto_update` (eine Zeile pro Node) - `node_name` (PK/unique) - `enabled` (bool) - `frequency` enum: `daily` | `weekly` - `weekday` (0-6, nur bei weekly) - `time_hhmm` (z. B. "03:00") — **pro Node eigene Zeit** - `scope` enum: `all` (alle VMs+CTs) | `security` (nur Security-Updates) ← Auswahl 3 - `vmid_filter` JSONB: optionale Liste einzelner VMIDs/CTs (leer = ganze Node) ← Auswahl 4 (einzelne waehlbar) - `reboot_policy`: fix **`notify_only`** (kein Auto-Reboot; Reboot-Notwendigkeit nur melden) - `last_run_at`, `last_status`, `last_summary` (JSONB: pro VM ok/fail/reboot_required) - intern: `time_hhmm`+`frequency`+`weekday` → Cron-Expression ableiten (fuer den Tick). ## Tick-Logik (`_auto_update_tick`) 1. 1x/Minute: alle `enabled` Node-Configs lesen, deren naechster Lauf faellig ist. 2. Pro faellige Node: Kandidaten ermitteln — VMs **und** CTs mit verfuegbaren Updates (CT==VM gleich behandeln), gefiltert nach `scope` (all/security) und `vmid_filter`. 3. Lauf ueber **`bulk-job`** starten (programmatisch, nicht via HTTP). 4. **Reboot:** nie automatisch. Wenn nach Update `reboot_required` → in `last_summary` markieren + **notify()-Event** `auto_update_reboot_required` (node + betroffene VMs). 5. Ergebnis in `last_run_at/status/summary`; notify-Event `auto_update_done` (ok/fail-Counts). ## Frontend — uebergreifendes Modal "Auto-Update planen" - Einstieg: globaler Button (z. B. im Task-/Dashboard-Header), oeffnet **ein** Modal mit **Tabelle aller Nodes**. - Pro Node-Zeile editierbar: **An/Aus**, **Frequenz** (Daily/Weekly als simple Auswahl), bei Weekly **Wochentag**, **Uhrzeit (HH:MM)**, **Scope** (Alle / nur Security), optional **VM/CT-Auswahl** (Aufklappen → Checkboxen je VM/CT der Node). - Anzeige: naechster Lauf, letzter Lauf + Status (ok/fail/Reboot-noetig-Badge). - Bewusst **einfach verstaendlich**: Daily/Weekly + Uhrzeit, KEIN roher Cron im UI (Cron wird intern abgeleitet). ## Backend-Router `auto_update_router.py` - `GET /auto-update` (alle Node-Configs + Nodes ohne Config als "aus") - `PUT /auto-update/{node_name}` (config setzen/aktualisieren) - `POST /auto-update/{node_name}/run-now` (sofort ausloesen, gleicher Pfad wie Tick) - alle mit `require_role("operator")` + **`check_node_scope`** (Mandanten!) — pro Node-Config darf nur, wer die Node im Scope hat. ## Akzeptanz - Modal listet alle (scope-sichtbaren) Nodes; pro Node eigene Frequenz/Uhrzeit/Scope speicherbar. - Faelliger Lauf aktualisiert VMs **und** CTs der Node gemaess Scope/Filter via `bulk-job`. - Reboot wird **nie** automatisch ausgefuehrt, aber gemeldet (notify + Summary-Badge). - Tick laeuft im bestehenden Scheduler-Loop (kein zweiter Loop). - Cross-Tenant: man kann nur Nodes im eigenen Scope konfigurieren/ausloesen. ## Bezug #123 (kanonischer bulk-job-Pfad — Voraussetzung/Wiederverwendung), Scheduler (`scheduler.py`, croniter), #108 (Tenant-Scope-Muster fuer den Router), notify-Pipeline. ## Branch `feat/node-auto-update-scheduler`
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
chinux/theProx#174
No description provided.