Simone
770ac1edf8
- Create a new document `plans/implementation-plan-A-B.md` that consolidates the implementation plans for the Python rewrite (Phase A) and the migration to Linux Mint (Phase B). - The document includes detailed sections such as executive summary, checklist, prerequisites, step-by-step activities, architectural hooks for future phases, risk matrix, and references. - Ensure the plan is self-contained, adhering to specified structure and style guidelines, and does not introduce new technologies or modify existing files.
4.4 KiB
4.4 KiB
Roadmap evolutiva — overview
Decisione presa: implementare prima Idea 1 (Python) + Idea 2 (host Linux) in sequenza, e solo dopo valutare Idea 3 (ESXi).
| Fase | Cosa | File di dettaglio |
|---|---|---|
| A | Rewrite in Python sull'host Windows attuale (codebase cross-platform-ready) | idea-1-python-rewrite.md |
| B | Migrazione host: Windows 11 + Workstation Pro → Linux Mint + Workstation Pro Linux | idea-2-linux-host.md |
| C | (Futuro, condizionato a A+B stabili) Aggiunta backend ESXi | idea-3-esxi-support.md |
1. Razionale dell'ordine
- Idea 1 prima di Idea 2: scrivere Python sapendo già che girerà anche
su Linux evita un doppio porting. Tutto il codice nuovo nasce
cross-platform (no path hardcoded
F:\, noGet-StoredCredential, noNew-PSSessioncome unica via). Idea 2 diventa un'operazione di "swap della base OS" con codice già pronto. - Workstation Pro su entrambi gli OS: scegliendo Workstation Pro anche
su Linux (binario
/usr/bin/vmrun, senza.exe) si mantiene lo stesso comandovmrune gli stessi VMX template — zero conversione VMDK→qcow2, zero rewrite del backend hypervisor. Idea 2 diventa un porting di plumbing (path, service manager, credential store) e non di logica. - ESXi dopo: una volta stabilizzato Python + Linux, l'introduzione di
ESXi è un nuovo backend dietro un'astrazione
VmBackend(introdotta già in fase A come hook di design); il core non cambia.
2. Sinergie sfruttate
- Python (Idea 1) abilita
pypsrp(WinRM cross-platform),paramiko(SSH cross-platform),keyring(Credential Manager su Win, Secret Service su Linux): un unico tooling che funziona su entrambi gli host. - Tenere VMware Workstation Pro su Linux (Idea 2) elimina la necessità di imparare libvirt/KVM ora; resta come opzione futura se Broadcom dismette Workstation Pro.
- L'astrazione
VmBackendintrodotta come "design hook" già in Idea 1 riduce a costo marginale l'aggiunta del backend ESXi (Idea 3) tramitepyVmomi.
3. Riepilogo prerequisiti per fase
| Fase | Prerequisiti host | Prerequisiti competenze |
|---|---|---|
| A | Python 3.11+ su Windows; ambiente venv in F:\CI\python\venv\ |
Python, pytest, pypsrp/paramiko |
| B | Hardware Linux Mint operativo; VMware Workstation Pro Linux installata; storage analogo a F:\CI\ |
systemd, bash, secret-tool, gestione utente di servizio |
| C | Hardware ESXi + licenza Essentials o superiore; account vSphere dedicato | pyVmomi, datastore/portgroup management |
4. Criteri di "fase completata"
- A done:
Invoke-CIJob.ps1retired; tutti i job CI passano viapython -m ci_orchestrator job ...; test pytest verdi; capacity burn-in 4 job concorrenti PASS sull'host Windows attuale. - B done: act_runner gira come systemd service su Linux Mint; tutti i
workflow esistenti (Windows + Linux build) PASS dal nuovo host; storage
migrato a
/var/lib/ci/; capacity burn-in PASS. - C done (se attivata): label
windows-build:esxioperativa con backend pyVmomi; canary su almeno 1 workflow di produzione per ≥1 settimana senza regressioni.
5. Cosa fare se A o B falliscono / si bloccano
- Stop in A: il sistema PowerShell attuale resta in produzione (rollback banale, niente è stato distrutto). La parte Python già scritta resta come modulo "side-by-side" non utilizzato.
- Stop in B: l'host Windows resta primario; eventuale runner Linux secondario può comunque essere utile per workload sperimentali (path "dual-host" descritto in idea-2-linux-host.md §7).
- Stop pianificato in C: nessun impatto — C è opzionale per definizione, Workstation Pro su Linux copre già il caso d'uso primario.