Zwei parallele Node-Agent-Implementierungen (Python + Rust) konsolidieren #2

New issue

Closed

opened 2026-06-01 06:46:18 +00:00 by chinux · 1 comment

chinux commented

2026-06-01 06:46:18 +00:00

Owner

Problem

Es existieren zwei vollstaendige Node-Agent-Implementierungen, die dieselbe Aufgabe erfuellen und parallel gepflegt werden:

Python: Node-Agent/theprox_agent/ -> via bundle.py zu Node-Agent/node_agent.py (~5000 Zeilen, proxmox_api.py allein ~79 KB)
Rust: Node-Agent/src/ (~5000 Zeilen, Binary theprox-node-agent-x86_64)

install_script defaultet auf Python: server/main.py:282 (variant: str = "python"), Rust nur per ?variant=rust. Beide Install-Pfade sind in main.py vorhanden (Python ~Z.820-866, Rust _make_install_script_rust ~Z.887-941).

Warum

Doppelte Pflege von ~10k Zeilen fuer identische Funktion. Drift-Risiko: ein Command kann sich im Rust-Dispatcher (Node-Agent/src/dispatcher.rs) anders verhalten als im Python-Dispatcher (theprox_agent/_agent_dispatcher.py), je nachdem welche Variante auf dem Node laeuft.

Fix-Plan

Entscheidung dokumentieren, welche Variante kanonisch ist (Empfehlung: Rust, da Single-Binary-Deploy ohne venv/Python-Abhaengigkeit).
Command-Coverage beider Dispatcher diffen und sicherstellen, dass die Zielvariante alle produktiv genutzten Commands abdeckt.
Den variant-Parameter und den unterlegenen Install-Pfad entfernen, Default umstellen.
Tote Variante aus dem Repo nehmen (separater Branch/Tag als Archiv falls gewuenscht).

Akzeptanzkriterien

Nur noch eine Agent-Implementierung im Repo / im Install-Flow.
install_script ohne variant-Weiche.
Kurze Notiz in README/notes, welche Variante warum gewaehlt wurde.

## Problem Es existieren zwei vollstaendige Node-Agent-Implementierungen, die dieselbe Aufgabe erfuellen und parallel gepflegt werden: - **Python**: `Node-Agent/theprox_agent/` -> via `bundle.py` zu `Node-Agent/node_agent.py` (~5000 Zeilen, `proxmox_api.py` allein ~79 KB) - **Rust**: `Node-Agent/src/` (~5000 Zeilen, Binary `theprox-node-agent-x86_64`) `install_script` defaultet auf Python: `server/main.py:282` (`variant: str = "python"`), Rust nur per `?variant=rust`. Beide Install-Pfade sind in `main.py` vorhanden (Python ~Z.820-866, Rust `_make_install_script_rust` ~Z.887-941). ## Warum Doppelte Pflege von ~10k Zeilen fuer identische Funktion. Drift-Risiko: ein Command kann sich im Rust-Dispatcher (`Node-Agent/src/dispatcher.rs`) anders verhalten als im Python-Dispatcher (`theprox_agent/_agent_dispatcher.py`), je nachdem welche Variante auf dem Node laeuft. ## Fix-Plan 1. Entscheidung dokumentieren, welche Variante kanonisch ist (Empfehlung: Rust, da Single-Binary-Deploy ohne venv/Python-Abhaengigkeit). 2. Command-Coverage beider Dispatcher diffen und sicherstellen, dass die Zielvariante alle produktiv genutzten Commands abdeckt. 3. Den `variant`-Parameter und den unterlegenen Install-Pfad entfernen, Default umstellen. 4. Tote Variante aus dem Repo nehmen (separater Branch/Tag als Archiv falls gewuenscht). ## Akzeptanzkriterien - Nur noch eine Agent-Implementierung im Repo / im Install-Flow. - `install_script` ohne `variant`-Weiche. - Kurze Notiz in README/notes, welche Variante warum gewaehlt wurde.

chinux added the

refactor

tech-debt

agent

labels

2026-06-01 06:46:18 +00:00

chinux commented

2026-06-01 06:57:32 +00:00

Author

Owner

Gap-Analyse Rust vs. Python — Ergebnis: Rust ist bevorzugbar

Command-Coverage-Diff (Python theprox_agent/_agent_dispatcher.py = 78 Actions vs. Rust src/):

Rust deckte bereits 72 von 78 Python-Commands ab — und hat zusätzlich Features, die Python nicht hat (host.update., agent.self_update, vm.self_update_all, vm/ct.log_tail_, vm.list/ct.list, node.info/node.storage).
Echte Lücken: nur 6 Commands.

Davon waren 2 aktiv vom Backend aufgerufen und liefen auf dem Rust-Agent ins "not implemented":

node.refresh ← monitor_router.py:145 (Refresh-Button)
rdp.get_vm_ip ← rdp_router.py:54, tunnel_router.py:47 (RDP-IP-Auflösung)

Die anderen 4 waren reine Verwaltungslücken: vm.config.set, storage.delete, backup.create_job, backup.update_job.

Alle 6 geschlossen → Branch `feat/rust-agent-parity`

Commit implementiert alle sechs, pattern-gleich zu den bestehenden Handlern:

5x in src/commands.rs (sync: qm set / pvesh delete|create|set / qm agent network)
node.refresh braucht Scan-Range aus AgentState, daher sauber durch commands_async.rs + dispatcher.rs durchgereicht (nutzt neue data::collect_refresh).

Diff: 4 Dateien, +138/-1. PR: main...feat/rust-agent-parity

⚠️ Vor Merge nötig (cc / lokal)

cargo build — in meiner Umgebung war keine Rust-Toolchain verfügbar, der Code ist nicht compile-verifiziert. Pattern-genau geschrieben, aber bitte gegenbauen.
cargo clippy drüberlaufen lassen.
Funktionstest gegen einen echten Node: node.refresh (Refresh-Button), RDP-Open (get_vm_ip), VM-Config ändern, Backup-Job anlegen/ändern, Storage-Volume löschen.

Danach: Konsolidierung

Sind die 6 verifiziert, ist Rust funktional vollständig → Python-Variante (theprox_agent/, node_agent.py, bundle.py, vm_buffer.py) + variant=python-Pfad in main.py entfernen, Default auf Rust. Damit erledigen sich auch #5 (generiertes Bundle) und #6 teilweise.

## Gap-Analyse Rust vs. Python — Ergebnis: Rust ist bevorzugbar Command-Coverage-Diff (Python `theprox_agent/_agent_dispatcher.py` = 78 Actions vs. Rust `src/`): - Rust deckte bereits **72 von 78** Python-Commands ab — und hat zusätzlich Features, die Python *nicht* hat (host.update.*, agent.self_update, vm.self_update_all, vm/ct.log_tail_*, vm.list/ct.list, node.info/node.storage). - Echte Lücken: **nur 6 Commands**. Davon waren **2 aktiv vom Backend aufgerufen** und liefen auf dem Rust-Agent ins `"not implemented"`: - `node.refresh` ← `monitor_router.py:145` (Refresh-Button) - `rdp.get_vm_ip` ← `rdp_router.py:54`, `tunnel_router.py:47` (RDP-IP-Auflösung) Die anderen 4 waren reine Verwaltungslücken: `vm.config.set`, `storage.delete`, `backup.create_job`, `backup.update_job`. ## Alle 6 geschlossen → Branch `feat/rust-agent-parity` Commit implementiert alle sechs, pattern-gleich zu den bestehenden Handlern: - 5x in `src/commands.rs` (sync: qm set / pvesh delete|create|set / qm agent network) - `node.refresh` braucht Scan-Range aus `AgentState`, daher sauber durch `commands_async.rs` + `dispatcher.rs` durchgereicht (nutzt neue `data::collect_refresh`). Diff: 4 Dateien, +138/-1. PR: main...feat/rust-agent-parity ## ⚠️ Vor Merge nötig (cc / lokal) 1. **`cargo build`** — in meiner Umgebung war keine Rust-Toolchain verfügbar, der Code ist *nicht* compile-verifiziert. Pattern-genau geschrieben, aber bitte gegenbauen. 2. `cargo clippy` drüberlaufen lassen. 3. Funktionstest gegen einen echten Node: node.refresh (Refresh-Button), RDP-Open (get_vm_ip), VM-Config ändern, Backup-Job anlegen/ändern, Storage-Volume löschen. ## Danach: Konsolidierung Sind die 6 verifiziert, ist Rust funktional vollständig → Python-Variante (`theprox_agent/`, `node_agent.py`, `bundle.py`, `vm_buffer.py`) + `variant=python`-Pfad in `main.py` entfernen, Default auf Rust. Damit erledigen sich auch #5 (generiertes Bundle) und #6 teilweise.

chinux referenced this issue

2026-06-01 08:10:43 +00:00

Node-Agent: Stub-Handler auditieren (set_interval no-op u. a.) — echte Parität sicherstellen #10

chinux referenced this issue from a commit

2026-06-01 12:18:09 +00:00

fix(repo): resolve open Gitea issues #1–#10

chinux referenced this issue from a commit

2026-06-01 12:18:34 +00:00

chore: close remaining issues resolved in f5111e7

chinux closed this issue

2026-06-01 12:18:34 +00:00

chinux referenced this issue