Simone
f965db71b3
idea-3- prefix was shared with idea-3-powershell-removal.md; rename the ESXi idea to idea-4-esxi-support.md and update the ideas-overview link. Pure rename, content unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
87 lines
5.2 KiB
Markdown
87 lines
5.2 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, dopo B stabile) Eliminazione dipendenza `pwsh` dall'host Linux | [idea-3-powershell-removal.md](idea-3-powershell-removal.md) |
|
|
| D | (Futuro, condizionato a C stabili) Aggiunta backend ESXi | [idea-4-esxi-support.md](idea-4-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 | Fase B stabile ≥1 settimana; `pwsh` ancora installato durante il porting | click, subprocess, pytest |
|
|
| D | 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): `pwsh` può essere disinstallato dall'host Linux
|
|
senza impatti operativi; `bench run`, `validate host` e `smoke run`
|
|
sostituiscono completamente i relativi `.ps1`; suite pytest verde ≥90%.
|
|
- **D 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 — gli script `.ps1` originali
|
|
restano funzionanti; `pwsh` resta installato. Il sistema continua a girare.
|
|
- **Stop pianificato in D**: nessun impatto — D è opzionale per definizione,
|
|
Workstation Pro su Linux copre già il caso d'uso primario.
|