Svom Science Ground Segment KP-3

Présentation au sujet: "Svom Science Ground Segment KP-3"— Transcription de la présentation:

1 Svom Science Ground Segment KP-3
3-4 juillet 2019

2 Mercredi Jeudi Au menu de ces 2 jours Le point sur la situation
Le data challenge 1 Rapports d’activités Jeudi PA/QA Orchestration Les outils installés à Orsay

3 Global planning Dates and number of all milestones not fully known yet Roughly only less of 1.5 years remaining for developments

4 KP-5 Strasbourg18 & 19 décembre 2019
LeS Réunions jalons 2019 KP-2 CEA Saclay 10 & 11 avril 2019 KP-3 Meudon 3 & 4 juillet 2019 KP-4 Toulouse 9 & 10 octobre 2019 KP-5 Strasbourg18 & 19 décembre 2019 Revue Cnes début octobre les 8 & 9 Livraison version alpha 13 décembre > 27 février 2020 Préparation CDR mi-décembre 2019 Clôture DC-1 fin mars 2020 ( ??? )

5 Terminer proprement l’intégration dc-0
Le plan de travail 2019 (1) Terminer proprement l’intégration dc-0 Laissé en stand-by : trop coûteux Corriger tous les problèmes de qualité Bien avancé : le cadre est en place Le taux de couverture des tests reste faible Mettre en place la procédure d’IC, DC L’intégration continue (IC) a bien avancé Le travail sur la livraison continue (DC) n’a pas commencé

6 Mettre en place l’utilisation de Jira
Le plan de travail 2019 (2) Mettre en place l’utilisation de Jira Trop ambitieux, donc reporté Mettre en place la sécurité Rien de sérieux encore en place mais prévu Implémenter l’authentification En bonne voie Initialiser le MXT IC Gros point noir

7 Développer les pipelines scientifiques
Le plan de travail 2019 (3) Développer les pipelines scientifiques En bonne voie Préparer les applications CP, GP, ToO, Monitor CP : le problème est posé mais non résolu GP : le problème est posé mais non résolu ToO : éventuellement reporté à plus tard (?) Monitor : en bonne voie Établir proprement l’architecture du FSC Respecter les principes de conception logicielle

8 FSGS version alpha (1) In progress postponed
The alpha version is expected : to accept incoming streams issued by the VHF stations, In progress to accept incoming messages sent by ground telescopes, postponed to authenticate and authorize securely Svom principals, to accept and manage user connections, Soon available to be capable of ingesting X-band data, to communicate with the instrument centers, In progress for EIC

9 FSGS version alpha (2) Not impossible Not done Why not ? In progress
The alpha version is expected : to communicate with the Chinese centers, Not impossible to manage problems caused by communication failures, Not done to run application servers giving access to mock scientific products, Why not ? to execute the set of scientific pipelines, In progress to broadcast alert messages, Almost ready to be sufficiently documented. Documented, not sufficiently

10

11 DC-1 specification Must be edited in Polarion It must consist of lists of work items test case A WI must describe a set of test steps Each section of the DC-1 spec has to come with a very short introduction DC1 definition will be frozen by July 3rd

12

13

14

15 MY OWN DC-1 Tasks Mise en place de Centreon WI FSC-2209 Service de gestion des certifs WI FSC-2235 Authentification des utilisateurs WI FSC-2236

16

17 Documents applicables
DNO/DA/AQ Spécification assurance qualité logiciel pour les développements avec des laboratoires QUAL_LOG_070 Application du plan assurance qualité logiciel Le plan d’assurance qualité logiciel du Laboratoire Responsable du Développement doit être validé par le CNES et est applicable à tous les développeurs. Le Laboratoire Responsable du Développement est garant de l'application de ce document chez ses partenaires/laboratoires. QUAL_LOG_150 Standard de codage Pour tout développement logiciel (y compris les logiciels de calcul), un standard de codage, validé par le CNES, doit être appliqué par tous les développeurs qui doivent en avoir la maitrise. QUAL_LOG_230 Bilan qualité Les contrôles qualité doivent être effectués au plus tôt, dès le démarrage de la phase de codage, puis périodiquement afin de s'assurer de la conformité et de la fiabilité du code et de l’application des plans (plan qualité, plan de développement etc.)

18 Software product assurance plan
Language and programming rules Main programming languages are Java, Javascript, Python. Use of other programming languages should be fully justified. Coding standards shall be applied when writing code of the software components. Coding standards for the project are : Sun standard for Java PEP8 standard for Python Google style guide for Javascript Software Metrics will be automatically collected by tools Every developer must comply with the software quality model Software controls are performed by SQAM SQAM provides feed back to the FSC team Developers must take action to correct discrepancies RFW/RFD will be emitted for identified residual discrepancies

19 CC in2p3 Production Intégration Qualité Cloud LAL Tests Développements
Le Work flow La procédure de mise en production : CC in2p3 Production docker-compose.yml Intégration Qualité Tests SonarQube Gitlab runners Dockerfile docker-compose.yml Cloud LAL Développements Expérimentation Sonar-scanner App.py Prog.java Dockerfile Labo

20 Integration First stage

21 Integration Second stage

22 Vérification des programmes python
Règles PEP8 à respecter Localement avec : pylint sonar-scanner Fichiers de configuration à fournir pytest — Unit testing framework Interactions avec gitlab-ci Utilisation de SonarQube Quality Gate de sonar par défault Quality Profiles de sonar Objectif : publication lors du KP-3 à Meudon

23 Vérification des programmes
Objectif à moitié atteint : La liste des projets n’est pas clairement fixée Le déclenchement par gitlab CI n’est pas complètement en place Les projets Java sont mieux traités C’est un peu plus délicat pour python Les dettes techniques semblent soutenables La couverture des tests est beaucoup trop faible

24