Bilan Studieuse 2023-01 about openfisca-france HOT 7 OPEN

Un immense merci @Sasha-Laniece pour ce travail de formalisation et de consolidation ! C'est très précieux 🙇

Harmonisation

Ces modifications […] doivent aussi faire l'objet d'une modification dans openfisca-core .

J'attire l'attention sur le fait que les noms choisis devront être discutés plus largement dans ce cadre ; on n'est donc pas à l'abri d'un renommage ultérieur, mais le cas échéant probablement meilleur grâce à la participation de personnes anglophones 🙂

on renomme le champ href en url

Ce point n'est pas présent dans l'exemple donné 🙂

API

Je suis personnellement très favorable à une modernisation du moteur de l'API web.

Charte

• Formaliser ces points dans un document.

from openfisca-france.

[ 6 - CHARTE D'USAGE - DROITS ET CONDITIONS ]
Dans cet atelier mené par @MattiSG , il a été rappelé qu'il faut:

• mettre à jour le modèle sur la zone de responsabilité
• rendre visible les travaux en cours
• indiquer ses zones d'expertise métier et répondre à la communauté
• respecter les règles de contribution (rappellées dans le Wiki )
• répondre aux questions à la suite d'une contribution
• pas d'exclusivité sur les zones législatives
• rendre accessible le code source sur la forge publique

Obligations :

• afficher la mention "Calculé par OpenFisca version XX" à côté des résultats et dans les mentions légales (avec un lien vers le site)
• référencer sa réutilisation sur le site OpenFisca (fait ici: #2003 (comment))
• correspondant.e
• ouvrir des issues
• partager ses statistiques d'usage
• informer des communications faites au sujet d'OpenFisca
• utiliser des bases de présentation partagées
• informer d'ajouts / outils annexes / expérimentations
• conditions sur le logo : non utilisation pour donner l'impression d'affiliation

ceci est une ébauche, @MattiSG ou @sandcha je vous laisse corriger et compléter

from openfisca-france.

[ 1 - L'HARMONISATION ]

Le chantier d'harmonisation, qui vise à rapprocher les paramètres d'OpenFisca-France de ceux des Barèmes-Ipp afin d'en faire un unique répertoire, a été démarré par @benjello, @sandcha, @eraviart et @Sasha-Laniece au printemps 2021 dans cette issue: #1519

Il s'est découpé en de nombreuses actions résumées ici:

• Initialisation : #1537
• 1 - Prélèvements sociaux : #1597
• 2 - Impôt sur le revenu : #1598
• 3 - Taxation du capital: #1599
• 6 - Prestations sociales: #1600
• 8 - Chômage et préretraites: #1602
• 9 - Marché du travail : #1603

Ce qui n'est pas rapproché car inutile dans OpenFisca-France (d'après @benjello )

• 4 - Taxation indirecte : #1604
• 5 - Fiscalité des entreprises: #1605
• 7 - Retraite: #1601
• 10 - Tarifs réglementés de l'énergie : #1606

Pour mener à bien ce travail, il reste encore quelques étapes:

• La création d'une tâche de CI pour maintenir le travail d'harmonisation PR ici (@sandcha )
• Passer le Validateur yaml de la CI en test 'bloquant' pour empêcher de détricoter l'harmonisation (@eraviart )
• Finir la migration côté IPP ( @benjello )
• Fusionner les répertoires !

from openfisca-france.

[ 2 - LA RFC DE NORMALISATION DES PARAMÈTRES ]

Lors de l'harmonisation, devant la disparité des formats observés dans les paramètres, on s'est posé la question des "bonnes pratiques" quant à la rédaction d'un yaml de paramètres.
S'est ensuivi un débat avec de nombreux échanges tous résumés dans la RFC #1672 .
Malheureusement le timing et la charge de travail des différents participants font qu'elle n'a pas été clôturée et les choses sont restées en suspens. Profitant de la présence de nombreux contributeurs lors de la Studieuse, nous avons voulu finaliser cette RFC.

Les actions suivantes ont été prises:

1 - Renommage et normalisation des champs des paramètres, avec précision de leur définition dans cette PR #1998 . En bref:

• description devient label
• ux_name devient short_label
• description_en devient label_en
• last_review devient last_value_still_valid_on
  Ces modifications seront poussées ici: #2001, et doivent aussi faire l'objet d'une modification dans openfisca-core .

2 - La normalisation du champ reference a fait l'objet d'un débat à part, dont les conclusions sont ici : #2002 . Les informations cruciales à retenir sont:

• la reference est OBLIGATOIRE
• on doit pouvoir trouver la valeur du paramètre EN UN CLIC (pour les décrets, utiliser la version originale)
• le format de l'URL est important
• on renomme le champ href en url

En pratique, on change le format pour mettre les références à côté de la value qu'elles concernent:

label: SMIC brut mensuel
values:
  2022-08-01:
    value: 1678.95
    reference:
        title: Arrêté du 29/07/2022
        href: https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000046113517
  2023-01-01:
    value: 1709.28
    reference:
        title: Décret 2022-1608 du 22/12/2022
        href: https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000046780043
metadata:
    short_label: SMIC brut mensuel
    last_value_still_valid_on: "2022-08-03"
    label_en: Minimum wage - SMIC (1970 -)

Pour mener à bien ce travail, il reste encore quelques étapes:

• Faire la PR de modification du format des références (avec un script automatique) (@eraviart ?)
• Faire les modifications correspondantes dans openfisca-core (@eraviart ou @sandcha ou @MattiSG ? )
• Rédiger ces décisions dans le Wiki, dans la partie Guide des Bonnes Pratiques : https://github.com/openfisca/openfisca-france/wiki/Bonnes-pratiques-de-mod%C3%A9lisation (@Sasha-Laniece )

from openfisca-france.

[ 3 - RÉFÉRENCEMENT DES PRODUITS ]

Suite à la demande de @MattiSG , chaque équipe a fourni des informations pour enrichir le site OpenFisca.org de toutes les applications du modèle.
Le dépôt de modification du site openfica est ici : https://github.com/openfisca/openfisca.org
La vitrine se voit ici : https://openfisca.org/fr/showcase/

from openfisca-france.

[ 5 - ÉCHANGE SUR LES CHOIX D'INSTANCIATION ]

CR d' @Olivier-Bernard-IMSA :
"
Cet atelier était à l’initiative de MesDroitsSociaux.
Nous nous sommes retrouvés à 2, @benoit-cty et moi pour échanger sur la manière dont nous utilisons et instancions le moteur OF pour répondre à nos besoins.
J’en profite pour le remercier pour toutes les informations et pistes d’améliorations qu’il a partagé concernant Python et le moteur OF, notre expertise côté MDS étant plus sur les architectures à base de Java.
Côté MDS, le besoin d’échanger sur cet atelier vient les difficultés que nous avons rencontré sur des tests de performances où notre service de simulation basé sur OF est notre facteur limitant de monté en charge. Les temps de réponses sont limitants et la consommation en mémoire nous interroge vis-à-vis de l’exploitabilité de la plateforme MDS.
Nos usages du moteur sont unitaires : un utilisateur va demander une simulation d’aide sur MDS à partir des données qui lui sont demandées et ou récupérées par MDS dans la sphère sociale et publique. Nous utilisons l’API Rest d’OF et OF est instancié dans un conteneur orchestré en tant que « pod » dans une infrastructure Cloud privé basée sur Kubernetes administrée par Rancher, et sur des nodes qui sont des VMs sur des ESXs VMWare. Les appels sont internes au cluster Kubernetes.
Nous avons été surpris par l’usage mémoire des instances d’OF (> 4 à 6GB), car c’est un service de calcul stateless, et que nous avons une bonne expérience sur côté moteur de calcul de prestations avec l’usage ODM, pour la tarification des feuilles de soins et pour la simulation et calcul de retraite, qui consomme surtout de la cpu.
Cet usage de mémoire nous interroge sur la pertinence de conserver OF en pod dans Kubernetes au regard d’une instanciation sur des VMs plus stables quitte à être moins flexible/scalables.
En effet, idéalement un service fournit par Kubernetes doit pouvoir démarrer très rapidement et être déplaçable facilement d’un nœud à un autre pour s’adapter aux besoins d’élasticité du cluster et de la disponibilité de ces nodes/nœuds. Or nos nodes sont actuellement des VMs relativement petite en mémoire, ce qui limite la capacité de Kubernetes à instancier des pods OF, et peut poser des difficultés d’exploitabilité : trouver un nœud suffisamment vide pour y instancier un pods OF par exemple.

Côté LexImpact, le cas d’usage métier est bien différent : le moteur OF est sollicité sur des jeux de données volumineux (et non pas unitaire par individu), pour évaluer sur des segments de population des impacts sur le budget de l’état de réformes. Ils l’utilisent donc essentiellement dans un cadre de calcul matriciel.
LexImpact n’utilise par l’API d’OF, ils ont fait le choix d’encapsuler OF dans leur produit et de mettre à disposition des services via une API Rest basé sur le framework Python FastAPI pour assurer de meilleures performances (ils considèrent l’API OF actuelle assez obsolète) et une généricité dans l’API qui répond mieux à leurs besoins.
Ils instancient cette application via une plateforme Proxmox, et expose le service via Gunicorn qui répartit le travail sur et 4 instances de conteneurs (LXC) contenant l’application.
Afin de limiter les sollicitation inutiles, ils utilisent un cache Redis pour stocker les résultats au regard des requêtes entrantes et les resservir.
Le monitoring est assuré via Prometheus (utilisé aussi côté MDS), FastApi y étant câblé.
Pour finir, ils utilisent le protocole Websocket entre la partie IHM côté navigateur vers l’applicatif afin d’assurer un affichage progressif des informations.

Benoit a aussi rencontré des problèmes de mémoire an arrivant jusqu’à 8GB, et ce malgré le mécanisme de débordement sur disque.
Il existe en effet un mécanisme d’OF de débordement sur disque, avec des possibilités de choix d’éviction des objets , qui se paramètre via un flag memory_config. Une trace est produite au démarrage permettant de vérifier si le mécanisme est actif et le débordement s’active à partir de 95% d’usage de la mémoire.
Il a utilisé un outil d’exploration de la mémoire, et c’est une piste à explorer un peu plus (par exemple https://blog.octo.com/rendre-son-code-python-performant-grace-au-profiling/ ), comme sur l’usage du GC.
Se posera aussi probablement des impacts sur l’architecture du produit OF nécessaires pour servir des cas d’usages qui sont potentiellement très différent : appels unitaires avec forte exigence réponse rapide et peu de besoin de matriciel versus appel unitaire avec fort volume de donnée.

Il a aussi constaté des temps de démarrage long. Il pense que c’est dû au mode de chargement de paramètres, et il pense que l’on pourrait beaucoup gagner en optimisant la fourniture des paramètres, comme par exemple de les fournir sous forme d’objets sérialisés via Pickle.
"

Les prochaines étapes pour remplir ces missions:

• Échanger avec d'autres usagers de l'API Web.
• Faire du profiling pour identifier les sources de problèmes.
• Migrer l'API Web OpenFisca sur un framework plus moderne, tel FastAPI ?
• Étudier comment accélérer le chargement des paramètres : parallélisation et/ou cache dans un seul fichier.

from openfisca-france.

[ 4 - UTILISATION DE CONDA AU LIEU DE PIP ]
Suite au travail de @benoit-cty dans ces PRs : #1778, #1779, #1786 et https://github.com/openfisca/openfisca-france/pull/17863 , on peut désormais publier OpenFisca-France dans un package Conda.

Le but n'est pas de remplacer pip mais d'offrir une alternative aux personnes qui le souhaitent.
L'équipe LexImpact utilise pip pour le développement en local et Conda sur le Centre d'Accès Sécurisé aux Données, CASD.
L'IPP utilise Conda pour installer Python mais utilise ensuite pip à l'intérieur de Conda.

Les prochaines étapes pour remplir ces missions:

• L'IPP regarde si Conda peut convenir à leur usage du CASD qui est différent de LexImpact. ( @bfabre01 ?)

from openfisca-france.