# Comment deployer un job Spark Dataproc serverless ?

## Migration du code

- Mise à jour du plugin Spark3
- => Approche abandonnée car il y a un couplage fort entre les versions de scala, de spark avec la plateforme sur laquelle on fait l'execution. On souhaite toujours pouvoir déployer sur Dataproc Compute Engine tant que le poc ne sera pas validé, et potentiellement continuer à le faire évoluer
- => Besoin d'un nouveau plugin

- Création d'un plungin dédié à Spark Serverless
- Fournit les bonnes dépendances
- Vérifie la version de scala
- S'assure des bons paramétrages de la JVM
- Plugin créé : https://gitlab.com/agilefabric/france/phenix/sbt-commons/-/merge_requests/73

- Migration des 5 jobs (+ 2 libs) réparties sur 2 répositories :
- https://gitlab.com/agilefabric/france/phenix/logistics-warehouse-operation-logistar-v2/-/merge_requests/13
- https://gitlab.com/agilefabric/france/phenix/logistics-warehouse-stock-logistar-v2/-/merge_requests/7

## Publication

- Publication d'un docker dans la registry de google (Artifact registry)
- Pratique car juste un docker à lancer en ligne de commande
- Impossibilité d'utiliser le module DockerRelease actuel d'sbt common actuel car l'image docker doit satisfaire certaines contraintes:
- Utilitaires requis dans l'image (procs, tini, libjemalloc2)
- User specifique (spark) devant exister avec des droits particuliers et appartenant à un groupe-id specifique
- => Besoin de créer un plugin sbt adhoc pour créer l'image (https://gitlab.com/agilefabric/france/phenix/sbt-commons/-/commits/dataproc_serverless_with_docker)
- => BLOCAGE : Necessité d'utiliser la registry de Google. Pas possible car les pipelines gitlab ne permettent pas de pousser vers cette registry (d'après Stephane Jeandeau dans un échange de mail)

- Publication d'un jar sur GCS (choix retenu)
- Il existe historiquement déjà un plugin permettant de releaser des jar sur GCS dans phenix-build
- => Besoin d'exporter cette fonctionnalité dans sbt-commons pour les repositories n'utilisant plus phenix-build (pour rappel, c'est un composant legacy)
- Production du plugin deploiement sur GCS dans sbt-commons : https://gitlab.com/agilefabric/france/phenix/sbt-commons/-/merge_requests/73
- Utilisation de ce plugin dans les 5 jobs
- - https://gitlab.com/agilefabric/france/phenix/logistics-warehouse-operation-logistar-v2/-/merge_requests/13
- https://gitlab.com/agilefabric/france/phenix/logistics-warehouse-stock-logistar-v2/-/merge_requests/7

## Phase de test

### Bucket cible pour les jars :
- project : vg1np-pf-phenix-caas-1a
- bucket : gs://phenix-spark-k8s-jars
- Bucket déjà existant + Seul projet sur lequel de pousser dessus via le pipeline (process de publication standard)
- In fine, est-ce la bonne cible ?

### CAAS ?
- Pas de permission pour exectuer du spark serverless en ligne de commande avec le service de rattaché à cette application
- => Création d'un custom role regroupant toutes les permissions nécessaires pour faire du dataproc serverless
- => Ce role a été rattaché au service account
- - BLOCAGE : Taoufiq nous à interdit de faire des tests dessus

### DEV ?
- /!\ Pas forcement de flux de donné alimenté sur l'ensemble des cas d'usage. - Même problème qu'en dev => Rajout du même role en dev aussi
- BLOCAGE : Pas de droit de créer de bucket pour acceuillir les releases

### TAT ?
- /!\ de données
- Pas de paserelle pour pouvoir accéder aux buckets de CAAS.
- => Tentative d'utilisation des buckets de TAT
- Pas de droits pour créer un bucket dédié
- => Utilisation d'un bucket de test déjà existant
- => Jars poussés à la main (il faut tester que cela fonctionne depuis le pipeline)
- Pas de permission pour exectuer du spark serverless en ligne de commande avec le service de rattaché à cette application
- Le service account de l'application n'a pas les droits nécessaires pour aller lire dans le bucket de test utilisé
- => Par défaut ce sont donc les points de José-Marie qui sont utilisés. Il n'avait pas ces droits, et ils viennent d'être fournis.
- BLOQUANT: Besoin d'un réseau faisant la liaison entre serverless et le compute engine (serverless étant une abstraction batie au dessus de compute engine)
- BLOQUANT: Besoin d'un history server

### REC ?
- Cible à privilégier car besoin de faire des recettes avec les POs par la suite.
- Rien d'entrepris pour l'instant

## Conclusions

- Plateforme non configurée au globale pour faire du dataproc serverless
- Il faut voir le problème dans sa globalité plutôt que de faire des essais isolés en tatonnant car on perd du temps
- En tant que devs, nous ne disposons pas de l'autonomie nécessaire pour mener le POC à son terme.
- Besoins :
- L'ensemble des environements doivent être compatible avec serverless (reseau adequat et history server à minima)
- Il faut pouvoir publier sur un bucket accessible depuis l'ensemble des environements
- Il faut que les services account des applications aient les droits nécessaires pour executer du serverless et accéder à ce bucket en lecture
- Il faut que l'on ai un moyen efficace de pouvoir, en tant que developpeur, lancer des executions spark dataproc (à minima jusqu'en recette) pour pouvoir tester efficacement. La solution optimale serait de pouvoir executer la ligne de commande du lancement de l'éxecution depuis nos services account de devs (ce qui permettrait de lancer les executions depuis nos PC).