CLOUD Workshop
- N. Mori ha presentato gli sviluppi fatti per HERD su servizi web e calcolo. I servizi web si basano su containers all-in-one e implementano una strategia di backup&restore basata su script di entrypoint customizzati per ogni servizio. Il modello di calcolo si basa sull'uso trasparente di risorse GRID e Cloud tramite Condor CE, con instradamento dei job sia su nodi GRID che su nodi containerizzati gestiti via Kubernetes.
- G. Mazzitelli ha presentato il lavoro fatto sul conmputing model di CYGNO e il progetto legato ala PNRR
- L. Anderlini ha presentato un'infrastruttura di calcolo basata su Kubernetes in via di sviluppo per AI_INFN. Il sistema di code si basa su Kueue (plugin nativo di Kubernetes per schedulare l'esecuzione di pod) ed e' attualmente in corso di sviluppo un componente chiamato interLink per dispacciare job Kueue su vari backend (Kueue, Condor, Slurm, ...).
Servizi web: il punto cruciale del lavoro di self-deplpoyment fatto da HERD e' dare accesso alle risorse ai membri della collaborazione mediante un'istanza IAM gestita dalla colalborazione e federata con gli IDP dei vari istituti partecipanti. L'approccio di CYGNO invece e' stato di utilizzare quanto messo a disposizione da INFN Cloud, interagendo con lo staff per personalizzare i servizi o crearne di nuovi. Dalla discussione e' emerso l'interesse a rivedere il lavoro fatto per HERD sul backup&restore dei servizi in una gestione basata su Kubernetes, per poter sfruttare i servizi di persistenza di Kubernetes e semplificare l'implementazione (quella attuale e' complessa e poco mantenibile). C'e' anche l'idea di rendere disponibile un set di servizi agli esperimenti che ne necessitassero aggiungendo alla PaaS un deployment Kubernetes+ArgoCD e fornendo dei template ArgoCD da customizzare.
Calcolo: la soluzione esplorata da HERD per istanziare worker nodes Condor su Kubernetes e' una possibile soluzione per integrare risorse cloud in un workflow basato su Condor. Tuttavia l'approccio basato su Kubernetes esplorato da AI_INFN potrebbe beneficiare del lavoro fatto in ambito enterprise su Kueue e le sue estensioni, oltre a permettere workflow piu' complessi e /o diversi rispetto a Condor. In questo senso e' fondamentale implementare interLink per poter sfruttare le risorse Condor gia' esistenti.
Un approccio diverso che consentirebbe di sfruttare pienamente le risorse a disposizione sia tramite Condor che tramite Kueue potrebbe essere di migrare interamente tutta l'infrastruttura di calcolo a Kubernetes e implementare una comunicazion tra il control plane di Kubernetes e lo schedd di Condor che consenta di istanziare nodi Condor in base alle necessita' dei job in coda sullo schedd, e di lanciare job Kueue sulle macchine dove non gira Condor.