TODO
Version 109 (Etienne Pallier, 12/19/2016 12:09 pm)
1 | 1 | Paul Carensac | h1. TODO |
---|---|---|---|
2 | 1 | Paul Carensac | |
3 | 51 | Etienne Pallier | |
4 | 1 | Paul Carensac | {{>toc}} |
5 | 51 | Etienne Pallier | |
6 | 1 | Paul Carensac | |
7 | 1 | Paul Carensac | --- |
8 | 1 | Paul Carensac | |
9 | 88 | Etienne Pallier | h2. %{margin-left:0px; font-weight:bold; font-size:25px; display:block; color:red;}Questions% |
10 | 1 | Paul Carensac | |
11 | 102 | Etienne Pallier | * Est-ce qu'on tient compte des Ephemerids lors de la création d'une requete Alerte ou pas ? |
12 | 88 | Etienne Pallier | * What is the 'flag' attribute ? (@AK) |
13 | 88 | Etienne Pallier | |
14 | 90 | Etienne Pallier | h2. %{margin-left:0px; font-weight:bold; font-size:25px; display:block; color:red;}DIVERS TODOs% |
15 | 88 | Etienne Pallier | |
16 | 98 | Etienne Pallier | |
17 | 109 | Etienne Pallier | * A étudier, et éventuellement adopter : |
18 | 109 | Etienne Pallier | |
19 | 109 | Etienne Pallier | * Django vraiment polymorphique : https://django-polymorphic.readthedocs.io/en/stable/quickstart.html#making-your-models-polymorphic |
20 | 109 | Etienne Pallier | |
21 | 109 | Etienne Pallier | * Projet Pyro (en remplacement de Celery ?) : https://pypi.python.org/pypi/Pyro4 |
22 | 108 | Etienne Pallier | |
23 | 106 | Etienne Pallier | * *Installation script* : l'écrire entièrement en Python (à la place du Bash) |
24 | 105 | Etienne Pallier | |
25 | 98 | Etienne Pallier | * UPDATES : |
26 | 98 | Etienne Pallier | |
27 | 106 | Etienne Pallier | * *Celery* => passer à la v4 (apparemment, il faut d'abord upgrader vers la v3.1.25 - cf http://docs.celeryproject.org/en/latest/whatsnew-4.0.html#whatsnew-4-0) |
28 | 98 | Etienne Pallier | * Django 1.11 (later) |
29 | 107 | Etienne Pallier | * Python 3.6 (later) |
30 | 98 | Etienne Pallier | |
31 | 100 | Etienne Pallier | * Introduire le composant Ephemerids (donne position lune, soleil, planètes pour la nuit...) |
32 | 101 | Etienne Pallier | * (?) Réintroduire la notion de RequestBuilder puisqu'il doit récupérer l'information donnée par Ephemerids, aussi bien pour construire une Routine que pour une Alerte |
33 | 100 | Etienne Pallier | |
34 | 98 | Etienne Pallier | * Compléter la grammaire de commandes PYROS à destination des telescopes et cameras (en essayant de faire des mises en commun) |
35 | 104 | Etienne Pallier | * *Mieux gérer l'héritage dans les modèles* : pyros_user => user, telescope => device, detector => device, etc... ; l'héritage doit être "transparent", ex: pyros_user.name = pyros_user.user.name, telescope.name = telescope.device.name, etc... |
36 | 103 | Etienne Pallier | => lire la partie " Les modèles parents classiques" de la section "L'héritage des modèles" de cet article : https://openclassrooms.com/courses/developpez-votre-site-web-avec-le-framework-django/techniques-avancees-dans-les-modeles |
37 | 97 | Etienne Pallier | * Ajouter le développement des simulateurs (en cours) dans la roadmap |
38 | 96 | Etienne Pallier | * Faire apparaitre une classe Factory à laquelle le Simulator fait appel pour créer ses instances du modèle ; c'est une classe utilitaire, à mettre à part, et utilisable par d'autres parties du code |
39 | 94 | Etienne Pallier | * Upgrade Django => 1.10 |
40 | 88 | Etienne Pallier | * Roue à filtre : doit pouvoir être associée à Camera ou bien à Tele (c’est prévu dans la BD ou pas ?) |
41 | 1 | Paul Carensac | * Il faut un système de LOG utilisé par tous les modules (Django en a un par défaut ?) |
42 | 89 | Etienne Pallier | * table filter_wheel : ajouter un champ "position" (numérique, c'est pas forcément un angle) |
43 | 92 | Etienne Pallier | * table filter : ajouter un champ "epaisseur équivalente" (donne le recul nécessaire à faire pour ajuster la focalisation) : un filtre a une épaisseur (a priori la même pour tous les filtres mais pas forcément) et on doit donc refocaliser pour en tenir compte |
44 | 91 | Etienne Pallier | * ajouter un NODE dans lequel on met le telescope (comme CADOR qui est un noeud regroupant plusieurs telescopes Tarot) : on peut par exemple imaginer que le GFT sera plus tard associé au telescope Butes du SPM ou au telescope chinois géré par le CSC (60cm), ou au GWAC du Chili |
45 | 90 | Etienne Pallier | * Créer un super agent SystemWatcher qui surveille tous les "agents" et les relance en cas de problème => ainsi, on n'a qu'un seul cron à exécuter pour relancer SystemWatcher s'il crashe (et c'est lui qui se charge de relancer les autres) |
46 | 1 | Paul Carensac | * Weather : plusieurs sources à traiter en parallèle, et en faire la synthèse ; plusieurs avantages: |
47 | 91 | Etienne Pallier | |
48 | 90 | Etienne Pallier | * redondance : si une source crashe, on a les autres |
49 | 90 | Etienne Pallier | * validité des données : on est davantage sûr d'un phénomène s'il est confirmé par plusieurs sources |
50 | 90 | Etienne Pallier | * identification de panne : si 1 seule source annonce la pluie et 2 autres non (ou l'inverse), on peut penser que cette source est défaillante |
51 | 1 | Paul Carensac | * complémentarité : les différentes sources n'apportent pas exactement la même information, elles peuvent se compléter (ex: cloud sensor et rain detector) |
52 | 98 | Etienne Pallier | |
53 | 98 | Etienne Pallier | * Ajouter la possibilité de planifier les séquences de la liste "to be planned" de CADOR: http://cador.obs-hp.fr/ros/scenes_cador.php |
54 | 98 | Etienne Pallier | |
55 | 98 | Etienne Pallier | * Ajouter des boutons de navigation sur le planning, permettant de passer au planning précédent (historique), ou suivant, ou de revenir à celui du jour : <PREC> <NOW> <SUCC> |
56 | 1 | Paul Carensac | |
57 | 52 | Etienne Pallier | h2. %{margin-left:0px; font-weight:bold; font-size:25px; display:block; color:red;}General tasks (notes Etienne Pallier)% |
58 | 1 | Paul Carensac | |
59 | 85 | Jeremy Barneron | * -Analysis (and calibration) module:- |
60 | 85 | Jeremy Barneron | -Pour l'instant, il est considéré qu'un plan forme une seule image. Lors de la fin de l'exécution d'un plan, la tâche execute_plan crée une tâche analysis à laquelle il envoie l'id du plan qui vient d'être exécuté. La tâche d'analysis- -récupère le plan en question, et récupère son nom. Pour le moment, les images crées ont le nom du plan correspondant. Il y a une ligne de TODO dans la tâche d'analysis qui dit de vérifier si le plan provient bien d'une alerte avant--de faire les analyses. Dans tous les cas, les calibrations sont appliquées.- |
61 | 85 | Jeremy Barneron | -=> Pour faire évoluer ce système d'image (puisqu'un plan crée plusieurs images), il faudra être capable de dire dans le execute_plan : une image vient d'être terminée par la caméra. Auquel cas on créera une tâche analysis à chaque-image crée, en lui donnant l'id du plan et le nom de l'image.- |
62 | 83 | Etienne Pallier | |
63 | 85 | Jeremy Barneron | * -Dashboard: s'inspirer du tableau de bord de l'ancien logiciel ROS- |
64 | 85 | Jeremy Barneron | -http://cador.obs-hp.fr/ros/manual/cador_actions.html- |
65 | 85 | Jeremy Barneron | -(cliquer par exemple sur Gardien)- |
66 | 81 | Etienne Pallier | |
67 | 85 | Jeremy Barneron | * -Données simulées : faire l'inventaire des données dont on a besoin (action en cours), données qui entrent (inputs) et qui sortent (output) de notre système- |
68 | 81 | Etienne Pallier | |
69 | 85 | Jeremy Barneron | * -Scheduler:- |
70 | 84 | Etienne Pallier | |
71 | 85 | Jeremy Barneron | * -Améliorer l'affichage du planning: ajouter une colonne "Observatory status" dans laquelle on affichera pour chaque séquence des icônes donnant le status en cours du ciel (cloudy, ...), le status des instruments (ex: icone d'un matériel en panne pour dire qu'on a un soucis sur le matériel)... ; en cliquant sur ces icones, on aurait plus de détails sur ce qui se passe- |
72 | 85 | Jeremy Barneron | * -Heure TU (UTC)- |
73 | 85 | Jeremy Barneron | * -N'afficher que la fenêtre de temps actuelle (mais on doit pouvoir scroller)- |
74 | 85 | Jeremy Barneron | * -Remplacer EXECUTED par COMPLETED, EXECUTED (partial) par INTERRUPTED, PENDING par EXPECTED- |
75 | 85 | Jeremy Barneron | * -Il faudrait une page qui montre toutes les séquences rejetées et exécutées (à préciser)- |
76 | 80 | Etienne Pallier | |
77 | 85 | Jeremy Barneron | * -Interface with GIC:- |
78 | 77 | Etienne Pallier | |
79 | 85 | Jeremy Barneron | * -Produire les données à envoyer au GIC dans un repertoire GIC/TO/ (pour que le GIC vienne les y chercher)- |
80 | 85 | Jeremy Barneron | * -Récupérer les données envoyées par le GIC depuis un autre repertoire GIC/FROM/- |
81 | 77 | Etienne Pallier | |
82 | 85 | Jeremy Barneron | * -Interface with FSC:- |
83 | 77 | Etienne Pallier | |
84 | 85 | Jeremy Barneron | * -Copier (ou linker) les données à envoyer au FSC dans un repertoire FSC/TO/ (ou autre solution ?)- |
85 | 77 | Etienne Pallier | |
86 | 77 | Etienne Pallier | |
87 | 85 | Jeremy Barneron | * -Tests unitaires (pyrosrun.sh unittest): les tests unitaires ne devraient pas faire appel à Celery (rabbitmq), or 2 tests ne passent pas si rabbitmq n'est pas lancé:- |
88 | 73 | Etienne Pallier | |
89 | 85 | Jeremy Barneron | * -test_full_creation (common.tests.RequestBuilderTests)- |
90 | 85 | Jeremy Barneron | * -test_change_all_working (alert_manager.tests.TestStrategyChange)- |
91 | 85 | Jeremy Barneron | * -=> il faut donc enlever le lien avec Celery dans ces tests (ou alors sortir ces tests des tests unitaires)- |
92 | 85 | Jeremy Barneron | -(Paul Carensac: La configuration de celery étant dans le settings.py, elle est exécutée dans tous les cas, et on associe celery à amqp dans ce fichier (ça fait peut-être quelque chose, même si je trouve ça bizarre))- |
93 | 73 | Etienne Pallier | |
94 | 73 | Etienne Pallier | |
95 | 85 | Jeremy Barneron | * -Observer:- |
96 | 70 | Etienne Pallier | |
97 | 85 | Jeremy Barneron | * -Refactoriser tasks.execute_plan{vis,nir}- |
98 | 85 | Jeremy Barneron | * -Gérer le Dithering : au début, c'est la camera NIR qui devait le gérer, mais ça risque d'être le Telescope !!! => va compliquer énormément les séquences d'observation.- |
99 | 85 | Jeremy Barneron | * -Organisation physique des données sur le disque- |
100 | 76 | Etienne Pallier | |
101 | 85 | Jeremy Barneron | * -Estimer le nombre de fichiers (et volume total) |
102 | 85 | Jeremy Barneron | * -3 espaces sur le disque (ou 3 disques ?):- |
103 | 85 | Jeremy Barneron | -(1) Un espace disque dédié aux images créées au fur et à mesure, nommé PRODUCED_DATA/- |
104 | 85 | Jeremy Barneron | -(2) Un espace disque dédié aux entités externes (GIC, FSC), nommé EXTERNAL_ENTITIES/- |
105 | 85 | Jeremy Barneron | -(3) Un espace disque dédié au téléchargement par les utilisateurs, nommé DOWNLOAD/- |
106 | 76 | Etienne Pallier | |
107 | 85 | Jeremy Barneron | * -Sur l’espace (1):- |
108 | 85 | Jeremy Barneron | -1 repertoire par nuit => pas très adapté car les AR et RR peuvent être exécutées sur plusieurs nuits.- |
109 | 85 | Jeremy Barneron | -=> préférer un repertoire par requete, que ce soit une alerte (AR), ou une routine (RR)- |
110 | 85 | Jeremy Barneron | -=> on peut même ajouter un sous-repertoire par sequence, ce qui aurait du sens puisque la sequence est l’unité de la planification.- |
111 | 85 | Jeremy Barneron | -=> il n’est sans doute pas nécessaire de descendre en dessous du niveau de la sequence (1 sous-repertoire par album c’est à dire par détecteur, puis 1 sous-repertoire par plan, quoi que...)- |
112 | 85 | Jeremy Barneron | -- Nom des dossiers : dès le début, un suffixe “_active” pour dire que c’est en cours de construction, puis supprimer ce suffixe quand la requête est terminée. Ex: alerte_1234_active/ => alerte_1234/- |
113 | 85 | Jeremy Barneron | -- Nom des images (même principe) : au début, un suffixe “.tmp”, qu’on supprime ensuite quand l’image est écrite entièrement.- |
114 | 76 | Etienne Pallier | |
115 | 85 | Jeremy Barneron | * -Sur l’espace (2):- |
116 | 85 | Jeremy Barneron | -1 repertoire FSC/- |
117 | 85 | Jeremy Barneron | -1 repertoire GIC/- |
118 | 85 | Jeremy Barneron | -Ces répertoires contiennent 2 sous-repertoire TO/ (ce qui doit être récupéré par l’entité) et FROM/ (ce que l’entité nous envoie).- |
119 | 85 | Jeremy Barneron | -A priori le répertoire FSC/ n’a besoin que d’un sous-répertoire TO/, et ce sous-rep pourrait soit contenir une COPIE des fichiers, soit des LIENS vers les fichiers originaux (solution préférable).- |
120 | 76 | Etienne Pallier | |
121 | 85 | Jeremy Barneron | * -Récupération des données d’une Request par son propriétaire (où tout autre user du même SP ?)- |
122 | 85 | Jeremy Barneron | -Ca risque d’être lourd à télécharger via du http, donc peut-on imaginer de donner un accès FTP direct sur le disque dur, dans un repertoire dédié à la récupération des données (dans lequel on aura recopié seulement les données demandées par l’utilisateur) => espace (3)- |
123 | 76 | Etienne Pallier | |
124 | 1 | Paul Carensac | |
125 | 76 | Etienne Pallier | |
126 | 76 | Etienne Pallier | |
127 | 70 | Etienne Pallier | |
128 | 85 | Jeremy Barneron | * -Sequence:- |
129 | 65 | Etienne Pallier | |
130 | 85 | Jeremy Barneron | * -Priority:- |
131 | 85 | Jeremy Barneron | -Une request est créée par un User qui appartient à un SP (Scientific Program).- |
132 | 85 | Jeremy Barneron | -La priorité de la Request est celle du SP.- |
133 | 85 | Jeremy Barneron | -Par contre, au sein de la Request, on pourra moduler la priorité de chaque séquence (cf /Sequence), afin de prioriser certaines sequences par rapport aux autres. Par défaut, cette variation de priorité sera nulle (0) pour chaque Sequence.- |
134 | 85 | Jeremy Barneron | -Par exemple, on pourra faire varier la priorité d’une Sequence de +ou- 5 par rapport à la priorité de la Request.- |
135 | 69 | Etienne Pallier | |
136 | 85 | Jeremy Barneron | * -Quota:- |
137 | 85 | Jeremy Barneron | -Les quotas sont attribués par le TAC (Time Allocation Committee) tous les 6 mois, pour chaque thème ou programme scientifique.- |
138 | 85 | Jeremy Barneron | -Le TAC attribue une lettre A (prioritaire), B (si il reste de la place), C (rejeté).- |
139 | 85 | Jeremy Barneron | -Au niveau du GFT, on traduit ces lettres en “grande priorité”, “priorité moyenne”, et “petite priorité” (le C n’est pas rejeté).- |
140 | 85 | Jeremy Barneron | -On estime alors le temps nécessaire pour le SP, et on le traduit en pourcentage.- |
141 | 85 | Jeremy Barneron | -On pourra donc attribuer un quota (en %) à chaque SP.- |
142 | 85 | Jeremy Barneron | -=> Le temps total de toutes les Requests (toutes leurs séquences) de tous les Users d’un même SP ne devra pas dépasser le quota du SP.- |
143 | 69 | Etienne Pallier | |
144 | 67 | Jeremy Barneron | * -Date: on doit pouvoir la donner sous 2 formes:- |
145 | 65 | Etienne Pallier | |
146 | 67 | Jeremy Barneron | * -“Tonight” => nuit en cours ou bien nuit qui arrive- |
147 | 67 | Jeremy Barneron | * -Date précise JJ/MM/AAAA (maximum à now + 7 nuits)- |
148 | 65 | Etienne Pallier | |
149 | 65 | Etienne Pallier | * Execution strategies: |
150 | 65 | Etienne Pallier | |
151 | 67 | Jeremy Barneron | * -Request level:- |
152 | 67 | Jeremy Barneron | -(default) "Best effort, do as much sequences as you can"- |
153 | 67 | Jeremy Barneron | -=> option: "All or nothing": if ANY sequence fails, request fails- |
154 | 65 | Etienne Pallier | |
155 | 67 | Jeremy Barneron | * -Sequence level- |
156 | 67 | Jeremy Barneron | -(default) “Optional sequence”- |
157 | 67 | Jeremy Barneron | -=> option “Mandatory sequence”: if THIS sequence fails, request fails- |
158 | 67 | Jeremy Barneron | -(default) “This night only”- |
159 | 67 | Jeremy Barneron | -=> option, “Reportable à la nuit suivante” (jusqu’à 7 nuits maxi)- |
160 | 65 | Etienne Pallier | |
161 | 67 | Jeremy Barneron | * -Période de visibilité JD1-JD2:- |
162 | 65 | Etienne Pallier | |
163 | 68 | Jeremy Barneron | * -Donnée par le logiciel ETC/IS- |
164 | 67 | Jeremy Barneron | * -c’est pour UNE NUIT (celle en cours, la prochaine, ou bien une date ultérieure pas trop loin pour que les users ne planifient pas trop en avance). Si la séquence n’a pas pu être exécutée pour cette nuit, il faut essayer de la -reprogrammer pour la nuit suivante (si le user a coché cette option) => il faudra donc recalculer le JD1-JD2 qui sera un peu différent pour chaque nuit, et ainsi de suite, jusqu’à ce qu’on arrive à une période de visibilité VIDE car- -le target n’est alors plus visible du tout- |
165 | 67 | Jeremy Barneron | * -D’autre part, il peut y en avoir plusieurs dans la nuit, et il faudra que l’ETC/IS les donne TOUTES:- |
166 | 65 | Etienne Pallier | |
167 | 67 | Jeremy Barneron | * -2 pour un target naturel (par exemple, il se couche en début de nuit, et se lève en fin de nuit, donc 2 périodes)- |
168 | 67 | Jeremy Barneron | * -Jusqu’à 12 pour l’ISS- |
169 | 67 | Jeremy Barneron | * -=> prévoir donc N périodes (au moins 2)- |
170 | 67 | Jeremy Barneron | * -=> obliger l’astronome à en CHOISIR une seule (s’il le souhaite, il pourra de toutes façons faire une autre séquence avec la 2ème période de visibilité…):- |
171 | 65 | Etienne Pallier | |
172 | 65 | Etienne Pallier | |
173 | 64 | Jeremy Barneron | * -Workflow du "démarrage du système" à documenter (tout se qui se déclenche quand on lance le logiciel pour la toute première fois...) : lancement du monitoring, qui à son tour lance un scheduling, …- |
174 | 62 | Etienne Pallier | |
175 | 64 | Jeremy Barneron | * -public/ : faut-il garder ce dossier qui ne contient qu’un seul dossier static/ ? (ce dossier static/ est-il utile à qqch ?)- |
176 | 62 | Etienne Pallier | |
177 | 64 | Jeremy Barneron | * -Démarrage: Ce n’est pas Monitoring mais Majordome qui doit lancer le 1er scheduling en début de nuit- |
178 | 62 | Etienne Pallier | |
179 | 64 | Jeremy Barneron | * -Fin de nuit: Majordome fait un system.pause(), ensuite une task de calibration est lancée qui doit vérifier que tout est ok avant de faire START (dome fermé, Tele fermé, …)- |
180 | 62 | Etienne Pallier | |
181 | 64 | Jeremy Barneron | * -Créer un mode DEV : jouer avec la variable DEBUG (ou autre ?) dans src/pyros/settings.py pour mettre à TRUE en mode DEV afin d’éviter d’avoir à commenter certaines lignes lors du lancement du workflow (sinon, c’est trop long)- |
182 | 62 | Etienne Pallier | |
183 | 64 | Jeremy Barneron | * -User : faire une view pour le profil- |
184 | 62 | Etienne Pallier | |
185 | 64 | Jeremy Barneron | * -RoutineManager : Faire un TEST import/export d’une requete- |
186 | 62 | Etienne Pallier | |
187 | 64 | Jeremy Barneron | * -Roue à filtre : doit pouvoir être associée à Camera ou bien à Tele (c’est prévu dans la BD ou pas ?)- |
188 | 62 | Etienne Pallier | |
189 | 56 | Jeremy Barneron | * -Observation_manager/Tasks : créer une classe mère héritant de Task, dont les classes filles (plan_vis et plan_ir) vont hériter- |
190 | 3 | Etienne Pallier | |
191 | 56 | Jeremy Barneron | * -Architecture projet (organisation dossiers):- |
192 | 39 | Etienne Pallier | |
193 | 56 | Jeremy Barneron | * -src/ : laisser seulement les applications, et mettre tous les autres dossiers (fixtures/, images/, ...) dans un dossier MISC/)- |
194 | 39 | Etienne Pallier | |
195 | 44 | Etienne Pallier | * RUN : |
196 | 44 | Etienne Pallier | |
197 | 56 | Jeremy Barneron | * -S'assurer que tous les prérequis sont présents et démarrés avant de lancer Pyros (sinon, générer un message d'erreur expliquant le problème):- |
198 | 44 | Etienne Pallier | |
199 | 56 | Jeremy Barneron | * -RabbitMQ- |
200 | 56 | Jeremy Barneron | * -Mysql (sauf si on a choisi sqlite)- |
201 | 44 | Etienne Pallier | |
202 | 44 | Etienne Pallier | |
203 | 44 | Etienne Pallier | |
204 | 45 | Etienne Pallier | * TESTS (intégration continue): |
205 | 1 | Paul Carensac | |
206 | 56 | Jeremy Barneron | * -Même remarque que pour le "RUN" ci-dessous concernant le check des prérequis- |
207 | 56 | Jeremy Barneron | * -Inclure "trial comet" dans les tests pour s'assurer que Comet est bien installé (+ "rm -r _trial_temp/" ensuite pour faire le ménage après le test)- |
208 | 56 | Jeremy Barneron | * -Mettre en place une exécution systématique des tests à chaque commit (unitaires + fonctionnels)- |
209 | 56 | Jeremy Barneron | -(pour faire plus simple, on peut imaginer que le serveur de test linux fasse un "git pull" toutes les 30mn, puis une exécution des tests, et l'envoi d'un email en cas de problème)- |
210 | 36 | Etienne Pallier | |
211 | 35 | Etienne Pallier | |
212 | 35 | Etienne Pallier | * Installation script: |
213 | 35 | Etienne Pallier | |
214 | 56 | Jeremy Barneron | * -Si l'environnement virtuel existe déjà, demander s'il doit être recréé (par défaut "Non")- |
215 | 56 | Jeremy Barneron | * -(NEW) Renommer le script install_requirements.sh en install.sh- |
216 | 56 | Jeremy Barneron | * -(NEW) Faciliter l'installation du logiciel complet avec CONDA, qui gère toutes les dépendances du logiciel, même les dépendances non Python (mysql, rabbitmq, ...), et c'est du multi-plateforme : (cf -https://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions)- |
217 | 35 | Etienne Pallier | |
218 | 25 | Etienne Pallier | * Pyros : |
219 | 1 | Paul Carensac | |
220 | 56 | Jeremy Barneron | * -Doit pouvoir être démarré indifféremment AVANT (par défaut) les devices, ou APRES (actuellement, le AVANT est TODO)- |
221 | 56 | Jeremy Barneron | * -De manière générale, doit être le plus possible "tolérant aux pannes"- |
222 | 56 | Jeremy Barneron | * -Doit être le plus générique et donc paramétrable possible- |
223 | 1 | Paul Carensac | |
224 | 25 | Etienne Pallier | |
225 | 23 | Etienne Pallier | * Django : |
226 | 12 | Etienne Pallier | |
227 | 56 | Jeremy Barneron | * -Upgrade to Django 1.10- |
228 | 56 | Jeremy Barneron | * -Remplacer le serveur web de "dev" (manage runserver, sur port 8000) par un vrai serveur web pour la "prod" (Apache pour les fichiers statiques sur port 80 + serveur d'application Python pour le code Python, par exemple gunicorn)- |
229 | 56 | Jeremy Barneron | -(cf https://projects.irap.omp.eu/projects/pyros/wiki/Project_Development#Serveur-Web)- |
230 | 23 | Etienne Pallier | |
231 | 56 | Jeremy Barneron | * -Comet installation : Include in the install_requirements.sh script (by using stable official version for Python 3 (when available) on Linux (and Mac) and Windows 10- |
232 | 1 | Paul Carensac | |
233 | 56 | Jeremy Barneron | * -git : Create a "dev" branch (do not write anymore on the "master" branch)- |
234 | 1 | Paul Carensac | |
235 | 25 | Etienne Pallier | * Simulators : |
236 | 1 | Paul Carensac | |
237 | 61 | Jeremy Barneron | * -on doit se rendre compte qu'ils sont "vivants" (ils seront progressivement remplacés par les vrais devices, mais resteront toujours utilisables à leur place)- |
238 | 25 | Etienne Pallier | |
239 | 61 | Jeremy Barneron | * -Le Monitoring doit les interroger régulièrement sur leur statut (check_status, DONE)- |
240 | 61 | Jeremy Barneron | * -Il doit stocker les statuts dans la BD (TODO)- |
241 | 61 | Jeremy Barneron | * -Ces statuts doivent être affichés au fur et à mesure sur la page web du "device" correspondant (Devices, Site, Weather) (TODO)- |
242 | 25 | Etienne Pallier | |
243 | 61 | Jeremy Barneron | * -quels sont les devices bloquants et non bloquants ?- |
244 | 25 | Etienne Pallier | |
245 | 60 | Jeremy Barneron | * -Bloquants: si indisponibles (en panne ou pas démarrés), Pyros met en pause le sous-système d'observation- |
246 | 60 | Jeremy Barneron | -Seules 3 fonctions restent toujours actives: alertes, monitoring, et serveur web (pour les routines et la surveillance)- |
247 | 25 | Etienne Pallier | |
248 | 60 | Jeremy Barneron | * -Telescope- |
249 | 60 | Jeremy Barneron | * -Camera VIS (???)- |
250 | 60 | Jeremy Barneron | * -PLC (weather + observation conditions + site)- |
251 | 25 | Etienne Pallier | |
252 | 60 | Jeremy Barneron | * -Non bloquants: si indisponibles (en panne ou pas démarrés), Pyros se contente d'en prendre note, et continue son fonctionnement normal tout en restant dans l'attente de leur redémarrage pour les réintégrer- |
253 | 25 | Etienne Pallier | |
254 | 60 | Jeremy Barneron | * -Camera VIS (???)- |
255 | 60 | Jeremy Barneron | * -Camera NIR- |
256 | 25 | Etienne Pallier | |
257 | 23 | Etienne Pallier | |
258 | 56 | Jeremy Barneron | * -Users: gérer les 3 profils (admin, expert, user)- |
259 | 23 | Etienne Pallier | |
260 | 50 | Etienne Pallier | * Scheduler : |
261 | 52 | Etienne Pallier | |
262 | 56 | Jeremy Barneron | * -Eviter que la vue du Scheduler s'affiche avec une erreur (IndexError) quand il n'y a aucun schedule dans la BD (http://127.0.0.1:8000/scheduler/) => idem pour toutes les autres vues de tous les modules- |
263 | 56 | Jeremy Barneron | * -Affichage d'un schedule : pour chaque ligne (séquence), ajouter une colonne à gauche qui donne le nom (short name) de la Request dont la séquence fait partie (quand on clique sur ce nom, on va vers une vue de la Request qui sera- -soit une AlertRequest soit une RoutineRequest)- |
264 | 56 | Jeremy Barneron | * -(non prioritaire, c'est juste un souhait) le rendre complètement autonome, indépendant du projet, afin qu'on puisse facilement le sortir du projet, et le proposer comme un composant générique utilisable dans n'importe quel autre- -logiciel ; il devra donc gérer ces communications avec les autres modules via des interfaces- |
265 | 52 | Etienne Pallier | |
266 | 50 | Etienne Pallier | |
267 | 49 | Etienne Pallier | |
268 | 14 | Etienne Pallier | * Doc : |
269 | 17 | Etienne Pallier | |
270 | 14 | Etienne Pallier | * TEST: |
271 | 14 | Etienne Pallier | |
272 | 56 | Jeremy Barneron | * -Unit tests : test of each module- |
273 | 56 | Jeremy Barneron | * -Functional tests (with Celery and simulators): complete workflow- |
274 | 14 | Etienne Pallier | |
275 | 14 | Etienne Pallier | * LAUNCH: |
276 | 14 | Etienne Pallier | |
277 | 56 | Jeremy Barneron | * -Start simulators- |
278 | 56 | Jeremy Barneron | * -Start Celery- |
279 | 56 | Jeremy Barneron | * -Start pyros- |
280 | 14 | Etienne Pallier | |
281 | 14 | Etienne Pallier | * USE: |
282 | 14 | Etienne Pallier | |
283 | 56 | Jeremy Barneron | * -Administration of the database: http://localhost:8000/admin- |
284 | 56 | Jeremy Barneron | * -Interacting with Pyros: http://localhost:8000- |
285 | 15 | Etienne Pallier | |
286 | 56 | Jeremy Barneron | * -Watch the environment: Devices, Site, Weather- |
287 | 56 | Jeremy Barneron | * -Watch the schedule: Schedule- |
288 | 56 | Jeremy Barneron | * -Watch the data processing (workflow): System (Dashboard)- |
289 | 56 | Jeremy Barneron | * -Submit a Routine Request (and get results): Routines- |
290 | 56 | Jeremy Barneron | * -Watch alerts: Alerts- |
291 | 56 | Jeremy Barneron | * -Simulate an Alert: Alerts (TODO: Un user "admin" doit pouvoir déclencher une alerte type depuis la page web Alerts)- |
292 | 56 | Jeremy Barneron | * -Manual operations on the Telescope : Devices/Telescope (TODO)- |
293 | 58 | Jeremy Barneron | * -Manage users : Users- |
294 | 22 | Etienne Pallier | |
295 | 14 | Etienne Pallier | |
296 | 1 | Paul Carensac | |
297 | 1 | Paul Carensac | --- |
298 | 1 | Paul Carensac | |
299 | 53 | Etienne Pallier | h2. %{margin-left:0px; font-weight:bold; font-size:25px; display:block; color:red;}Applications tasks (notes Paul Carensac)% |
300 | 2 | Paul Carensac | |
301 | 2 | Paul Carensac | h3. Dashboard |
302 | 2 | Paul Carensac | |
303 | 59 | Jeremy Barneron | * -Create the backoffice views as the modules are integrated in pyros- |
304 | 59 | Jeremy Barneron | * -Think about a system of permissions- |
305 | 2 | Paul Carensac | |
306 | 2 | Paul Carensac | h3. Scheduler |
307 | 2 | Paul Carensac | |
308 | 2 | Paul Carensac | * views |
309 | 2 | Paul Carensac | |
310 | 59 | Jeremy Barneron | * -Link the main page to the current schedule instead of the simulation page- |
311 | 59 | Jeremy Barneron | * -Show user sequences in the schedules (with links)- |
312 | 59 | Jeremy Barneron | * -Give accces to old schedules (day / days before / all end-night plannings / all plannings)- |
313 | 59 | Jeremy Barneron | * -Give access to the refused sequences of a schedule, and the reasons of rejects- |
314 | 2 | Paul Carensac | |
315 | 2 | Paul Carensac | * scheduler |
316 | 2 | Paul Carensac | |
317 | 59 | Jeremy Barneron | * -Verification when there are not fields in the scheduler tables (index out of range)- |
318 | 59 | Jeremy Barneron | * -Change the system to determine night start/end (they must be given in parameter, only if first_schedule is True)- |
319 | 59 | Jeremy Barneron | * -Store the reasons of rejects (create a new attribute, in shs ?)- |
320 | 59 | Jeremy Barneron | * -What is the 'flag' attribute ? (@AK)- |
321 | 59 | Jeremy Barneron | * -Do not create the execute_sequence tasks if it's not the night (- 120 seconds)- |
322 | 59 | Jeremy Barneron | * -Priority and quota computing- |
323 | 59 | Jeremy Barneron | * -Quotas evolution- |
324 | 59 | Jeremy Barneron | * -Blank space filling- |
325 | 59 | Jeremy Barneron | * -At the end of a scheduling send, it to the IC ?- |
326 | 2 | Paul Carensac | |
327 | 2 | Paul Carensac | h3. Alert Manager |
328 | 2 | Paul Carensac | |
329 | 2 | Paul Carensac | * Web : |
330 | 2 | Paul Carensac | |
331 | 59 | Jeremy Barneron | * -Print if there is an alert in progress in the main page- |
332 | 59 | Jeremy Barneron | * -Link the alerts to their status and results- |
333 | 2 | Paul Carensac | |
334 | 59 | Jeremy Barneron | * -Connect to a real VOEvent broker- |
335 | 2 | Paul Carensac | |
336 | 59 | Jeremy Barneron | * -Determine the communication with FSC for strategy change- |
337 | 2 | Paul Carensac | |
338 | 2 | Paul Carensac | * VOEvents : |
339 | 2 | Paul Carensac | |
340 | 59 | Jeremy Barneron | * -Extract the good fields (see AK Q&A 07/01/2016)- |
341 | 59 | Jeremy Barneron | * -Fill the request & alerts objects- |
342 | 59 | Jeremy Barneron | * -Use strategies to build a request- |
343 | 59 | Jeremy Barneron | * -Possibility to change the default strategy- |
344 | 59 | Jeremy Barneron | * -Handle VOEvent updates- |
345 | 59 | Jeremy Barneron | * -Be careful to not create 2 alerts for a same GRB, seen by 2 different satellites- |
346 | 2 | Paul Carensac | |
347 | 2 | Paul Carensac | |
348 | 2 | Paul Carensac | h3. Analyzer |
349 | 2 | Paul Carensac | |
350 | 59 | Jeremy Barneron | * -Apply the calibrations in the right function- |
351 | 59 | Jeremy Barneron | * -Apply the analyses only if it's a GRB- |
352 | 59 | Jeremy Barneron | * -Implement the analyses- |
353 | 59 | Jeremy Barneron | * -Send analyses to FSC- |
354 | 2 | Paul Carensac | |
355 | 2 | Paul Carensac | |
356 | 2 | Paul Carensac | h3. Majordome |
357 | 2 | Paul Carensac | |
358 | 2 | Paul Carensac | * TaskManager |
359 | 2 | Paul Carensac | |
360 | 59 | Jeremy Barneron | * -When a sequence is cancelled, give back the quota to the user- |
361 | 59 | Jeremy Barneron | * -In case of alert, do not stop the ongoing plan, and make the instruments abort- |
362 | 2 | Paul Carensac | |
363 | 2 | Paul Carensac | * execute_sequence |
364 | 2 | Paul Carensac | |
365 | 59 | Jeremy Barneron | * -Add the PLC checks at start (to see if we do the slew)- |
366 | 59 | Jeremy Barneron | * -Use the global telescope (instead of creating one here)- |
367 | 59 | Jeremy Barneron | * -Give first_schedule as false when a scheduling is launched- |
368 | 59 | Jeremy Barneron | * -Remove the default countdown (1, for tests)- |
369 | 2 | Paul Carensac | |
370 | 2 | Paul Carensac | * system_pause |
371 | 2 | Paul Carensac | |
372 | 59 | Jeremy Barneron | * -Abort the instruments- |
373 | 59 | Jeremy Barneron | * -Stop the execution tasks- |
374 | 2 | Paul Carensac | |
375 | 2 | Paul Carensac | * system_restart |
376 | 2 | Paul Carensac | |
377 | 59 | Jeremy Barneron | * -Start a scheduling- |
378 | 2 | Paul Carensac | |
379 | 2 | Paul Carensac | * change_obs_conditions |
380 | 2 | Paul Carensac | |
381 | 59 | Jeremy Barneron | * -Change sequences status (if needed)- |
382 | 59 | Jeremy Barneron | * -If some status changed, re-launch a scheduling- |
383 | 2 | Paul Carensac | |
384 | 2 | Paul Carensac | h3. Monitoring |
385 | 2 | Paul Carensac | |
386 | 2 | Paul Carensac | * views |
387 | 2 | Paul Carensac | |
388 | 59 | Jeremy Barneron | * -Move the dashboard here- |
389 | 59 | Jeremy Barneron | * -Print the instrument status- |
390 | 59 | Jeremy Barneron | * -Print PLC informations (with the evolution)- |
391 | 59 | Jeremy Barneron | * -In the dashboard screens, put scroll on each screen to see the old logs- |
392 | 2 | Paul Carensac | |
393 | 2 | Paul Carensac | * Monitoring task |
394 | 2 | Paul Carensac | |
395 | 59 | Jeremy Barneron | * -Uncomment the scheduling at the beginning- |
396 | 59 | Jeremy Barneron | * -Implement night start/end computation- |
397 | 59 | Jeremy Barneron | * -Initialize communication with the instruments- |
398 | 59 | Jeremy Barneron | * -Configure intruments at start- |
399 | 59 | Jeremy Barneron | * -Send software versions to the IC- |
400 | 59 | Jeremy Barneron | * -Initialize connection with PLC- |
401 | 59 | Jeremy Barneron | * -After the starting actions, loop to wait for the instruments configuration to be finished- |
402 | 59 | Jeremy Barneron | * -Ask PLC for status- |
403 | 59 | Jeremy Barneron | * -Ask filter wheel for status- |
404 | 59 | Jeremy Barneron | * -Store the instruments & PLC status- |
405 | 59 | Jeremy Barneron | * -Send all status to IC- |
406 | 59 | Jeremy Barneron | * -Analyse PLC status (obs conditions, ...)- |
407 | 59 | Jeremy Barneron | * -Create tasks of obs condition changes- |
408 | 59 | Jeremy Barneron | * -At the beginning of the loop, ping the DISABLED devices. If they answer, change their status (TBD), and do their initialization (ex: If it's a camera, set its temperature to -150°)- |
409 | 2 | Paul Carensac | |
410 | 2 | Paul Carensac | h3. Observation Manager |
411 | 2 | Paul Carensac | |
412 | 2 | Paul Carensac | * execute_plan : |
413 | 2 | Paul Carensac | |
414 | 59 | Jeremy Barneron | * -Uncomment the instruments_ready waiting function- |
415 | 59 | Jeremy Barneron | * -Uncomment the observation_ending waiting function- |
416 | 59 | Jeremy Barneron | * -Try to remove code duplication (plan_execution_vis & plan_execution_nir)- |
417 | 59 | Jeremy Barneron | * -Determine what needs to be done at the end of an observation- |
418 | 2 | Paul Carensac | |
419 | 2 | Paul Carensac | * create_calibrations : |
420 | 2 | Paul Carensac | |
421 | 59 | Jeremy Barneron | * -Make the calibration images- |
422 | 59 | Jeremy Barneron | * -Generate super images- |
423 | 59 | Jeremy Barneron | * -Send them to the IC- |
424 | 2 | Paul Carensac | |
425 | 2 | Paul Carensac | h3. Routine Manager |
426 | 2 | Paul Carensac | |
427 | 2 | Paul Carensac | * Web |
428 | 2 | Paul Carensac | |
429 | 59 | Jeremy Barneron | * -Put the goods fields (for coordinates etc)- |
430 | 59 | Jeremy Barneron | * -Only propose the objects that matches the conditions (ex: scientific programs of the user only)- |
431 | 59 | Jeremy Barneron | * -Do all the needed checks- |
432 | 59 | Jeremy Barneron | * -Add automatic computation of JD1/JD2- |
433 | 59 | Jeremy Barneron | * -Add checkbox for JD / GD- |
434 | 59 | Jeremy Barneron | * -Add options : copy my sequence on x days, and authorise report- |
435 | 59 | Jeremy Barneron | * -Add ETC-IS simulation- |
436 | 59 | Jeremy Barneron | * -Add help for new users (and for it the first time an account come on the page)- |
437 | 2 | Paul Carensac | |
438 | 2 | Paul Carensac | * Do more checks at unserialization |
439 | 2 | Paul Carensac | |
440 | 2 | Paul Carensac | * views |
441 | 2 | Paul Carensac | |
442 | 59 | Jeremy Barneron | * -When saving, do more checks on coordinates, jd1/2 etc- |
443 | 59 | Jeremy Barneron | * -Uncomment filter for alerts removing- |
444 | 59 | Jeremy Barneron | * -When submitting, use the monitoring to determine sequences status- |
445 | 59 | Jeremy Barneron | * -When submitting, modify the first_schedule to False, when scheduling- |
446 | 59 | Jeremy Barneron | * -When unsubmitting, uncomment the check for EXED and EXING removing- |
447 | 59 | Jeremy Barneron | * -When unsubmitting, uncomment the scheduling and change the first_schedule to False- |
448 | 2 | Paul Carensac | |
449 | 2 | Paul Carensac | |
450 | 2 | Paul Carensac | h3. User Manager |
451 | 2 | Paul Carensac | |
452 | 59 | Jeremy Barneron | * -Password recovery- |
453 | 59 | Jeremy Barneron | * -Profile page- |
454 | 59 | Jeremy Barneron | * -User validation by administrator / commission- |
455 | 59 | Jeremy Barneron | * -Handle permissions and access- |
456 | 2 | Paul Carensac | |
457 | 2 | Paul Carensac | h3. Common |
458 | 2 | Paul Carensac | |
459 | 59 | Jeremy Barneron | * -Change the 'first_schedule' to False at the end of RequestBuilder.validate()- |
460 | 32 | Paul Carensac | |
461 | 32 | Paul Carensac | h3. Devices |
462 | 32 | Paul Carensac | |
463 | 59 | Jeremy Barneron | * -When a socket connection fails (exception thrown), set the device to DISABLED (or that kind of status) in the DB, and create a system_pause task (majordome)- |