« Previous -
Version 59/113
(diff) -
Next » -
Current version
Jeremy Barneron, 09/30/2016 03:38 pm
TODO¶
List of tasks by application, and general tasks (organization, tools, ...)
ATTENTION, IL FAUT EFFACER LES ITEMS DE CETTE TODOLIST AU FUR ET A MESURE QU'ILS SONT MIS DANS LES DEMANDES REDMINE
General tasks (notes Etienne Pallier)¶
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
Architecture projet (organisation dossiers):src/ : laisser seulement les applications, et mettre tous les autres dossiers (fixtures/, images/, ...) dans un dossier MISC/)
- RUN :
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):RabbitMQMysql (sauf si on a choisi sqlite)
- TESTS (intégration continue):
Même remarque que pour le "RUN" ci-dessous concernant le check des prérequisInclure "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)Mettre en place une exécution systématique des tests à chaque commit (unitaires + fonctionnels)(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)
- Installation script:
Si l'environnement virtuel existe déjà, demander s'il doit être recréé (par défaut "Non")Renommer le script install_requirements.sh en install.shFaciliter 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)
- Pyros :
Doit pouvoir être démarré indifféremment AVANT (par défaut) les devices, ou APRES (actuellement, le AVANT est TODO)De manière générale, doit être le plus possible "tolérant aux pannes"Doit être le plus générique et donc paramétrable possible
- Django :
Upgrade to Django 1.10Remplacer 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)(cf https://projects.irap.omp.eu/projects/pyros/wiki/Project_Development#Serveur-Web)
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
git : Create a "dev" branch (do not write anymore on the "master" branch)
- Simulators :
- on doit se rendre compte qu'ils sont "vivants" (ils seront progressivement remplacés par les vrais devices, mais resteront toujours utilisables à leur place)
- Le Monitoring doit les interroger régulièrement sur leur statut (check_status, DONE)
- Il doit stocker les statuts dans la BD (TODO)
- Ces statuts doivent être affichés au fur et à mesure sur la page web du "device" correspondant (Devices, Site, Weather) (TODO)
- quels sont les devices bloquants et non bloquants ?
- Bloquants: si indisponibles (en panne ou pas démarrés), Pyros met en pause le sous-système d'observation
Seules 3 fonctions restent toujours actives: alertes, monitoring, et serveur web (pour les routines et la surveillance)- Telescope
- Camera VIS (???)
- PLC (weather + observation conditions + site)
- 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
- Camera VIS (???)
- Camera NIR
- Bloquants: si indisponibles (en panne ou pas démarrés), Pyros met en pause le sous-système d'observation
- on doit se rendre compte qu'ils sont "vivants" (ils seront progressivement remplacés par les vrais devices, mais resteront toujours utilisables à leur place)
Users: gérer les 3 profils (admin, expert, user)
- Scheduler :
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 modulesAffichage 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 serasoit une AlertRequest soit une RoutineRequest)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 autrelogiciel ; il devra donc gérer ces communications avec les autres modules via des interfaces
- Doc :
- TEST:
Unit tests : test of each moduleFunctional tests (with Celery and simulators): complete workflow
- LAUNCH:
Start simulatorsStart CeleryStart pyros
- USE:
Administration of the database: http://localhost:8000/adminInteracting with Pyros: http://localhost:8000Watch the environment: Devices, Site, WeatherWatch the schedule: ScheduleWatch the data processing (workflow): System (Dashboard)Submit a Routine Request (and get results): RoutinesWatch alerts: AlertsSimulate an Alert: Alerts (TODO: Un user "admin" doit pouvoir déclencher une alerte type depuis la page web Alerts)Manual operations on the Telescope : Devices/Telescope (TODO)Manage users : Users
- TEST:
Applications tasks (notes Paul Carensac)¶
Dashboard¶
Create the backoffice views as the modules are integrated in pyrosThink about a system of permissions
Scheduler¶
- views
Link the main page to the current schedule instead of the simulation pageShow user sequences in the schedules (with links)Give accces to old schedules (day / days before / all end-night plannings / all plannings)Give access to the refused sequences of a schedule, and the reasons of rejects
- scheduler
Verification when there are not fields in the scheduler tables (index out of range)Change the system to determine night start/end (they must be given in parameter, only if first_schedule is True)Store the reasons of rejects (create a new attribute, in shs ?)What is the 'flag' attribute ? (@AK)Do not create the execute_sequence tasks if it's not the night (120 seconds)-Priority and quota computingQuotas evolutionBlank space fillingAt the end of a scheduling send, it to the IC ?
Alert Manager¶
- Web :
Print if there is an alert in progress in the main pageLink the alerts to their status and results
Connect to a real VOEvent broker
Determine the communication with FSC for strategy change
- VOEvents :
Extract the good fields (see AK Q&A 07/01/2016)Fill the request & alerts objectsUse strategies to build a requestPossibility to change the default strategyHandle VOEvent updatesBe careful to not create 2 alerts for a same GRB, seen by 2 different satellites
Analyzer¶
Apply the calibrations in the right functionApply the analyses only if it's a GRBImplement the analysesSend analyses to FSC
Majordome¶
- TaskManager
When a sequence is cancelled, give back the quota to the userIn case of alert, do not stop the ongoing plan, and make the instruments abort
- execute_sequence
Add the PLC checks at start (to see if we do the slew)Use the global telescope (instead of creating one here)Give first_schedule as false when a scheduling is launchedRemove the default countdown (1, for tests)
- system_pause
Abort the instrumentsStop the execution tasks
- system_restart
Start a scheduling
- change_obs_conditions
Change sequences status (if needed)If some status changed, re-launch a scheduling
Monitoring¶
- views
Move the dashboard herePrint the instrument statusPrint PLC informations (with the evolution)In the dashboard screens, put scroll on each screen to see the old logs
- Monitoring task
Uncomment the scheduling at the beginningImplement night start/end computationInitialize communication with the instrumentsConfigure intruments at startSend software versions to the ICInitialize connection with PLCAfter the starting actions, loop to wait for the instruments configuration to be finishedAsk PLC for statusAsk filter wheel for statusStore the instruments & PLC statusSend all status to ICAnalyse PLC status (obs conditions, ...)Create tasks of obs condition changesAt 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°)
Observation Manager¶
- execute_plan :
Uncomment the instruments_ready waiting functionUncomment the observation_ending waiting functionTry to remove code duplication (plan_execution_vis & plan_execution_nir)Determine what needs to be done at the end of an observation
- create_calibrations :
Make the calibration imagesGenerate super imagesSend them to the IC
Routine Manager¶
- Web
Put the goods fields (for coordinates etc)Only propose the objects that matches the conditions (ex: scientific programs of the user only)Do all the needed checksAdd automatic computation of JD1/JD2Add checkbox for JD / GDAdd options : copy my sequence on x days, and authorise reportAdd ETC-IS simulationAdd help for new users (and for it the first time an account come on the page)
- Do more checks at unserialization
- views
When saving, do more checks on coordinates, jd1/2 etcUncomment filter for alerts removingWhen submitting, use the monitoring to determine sequences statusWhen submitting, modify the first_schedule to False, when schedulingWhen unsubmitting, uncomment the check for EXED and EXING removingWhen unsubmitting, uncomment the scheduling and change the first_schedule to False
User Manager¶
Password recoveryProfile pageUser validation by administrator / commissionHandle permissions and access
Common¶
Change the 'first_schedule' to False at the end of RequestBuilder.validate()
Devices¶
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)