Simone
80 lines
4.4 KiB
Markdown
80 lines
4.4 KiB
Markdown
# 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](idea-1-python-rewrite.md) |
|
|
| B | Migrazione host: Windows 11 + Workstation Pro → Linux Mint + Workstation Pro Linux | [idea-2-linux-host.md](idea-2-linux-host.md) |
|
|
| C | (Futuro, condizionato a A+B stabili) Aggiunta backend ESXi | [idea-3-esxi-support.md](idea-3-esxi-support.md) |
|
|
|
|
---
|
|
|
|
## 1. Razionale dell'ordine
|
|
|
|
1. **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:\`, no `Get-StoredCredential`,
|
|
no `New-PSSession` come unica via). Idea 2 diventa un'operazione di
|
|
"swap della base OS" con codice già pronto.
|
|
2. **Workstation Pro su entrambi gli OS**: scegliendo Workstation Pro anche
|
|
su Linux (binario `/usr/bin/vmrun`, senza `.exe`) si mantiene **lo stesso
|
|
comando `vmrun` e 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.
|
|
3. **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 `VmBackend` introdotta come "design hook" già in Idea 1
|
|
riduce a costo marginale l'aggiunta del backend ESXi (Idea 3) tramite
|
|
`pyVmomi`.
|
|
|
|
---
|
|
|
|
## 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.ps1` retired; tutti i job CI passano via
|
|
`python -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:esxi` operativa 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](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.
|