TODO
Version 13 (Etienne Pallier, 08/10/2016 03:13 pm) → Version 14/113 (Etienne Pallier, 08/10/2016 04:44 pm)
h1. TODO
List of tasks by application, and general tasks (organization, tools, ...)
{{>toc}}
---
h2. %{margin-left:0px; font-weight:bold; font-size:25px; display:block; color:red;}General tasks%
* DJANGO :
* Upgrade to Django 1.10
* Remplacer le serveur web de "dev" (manage runserver) par un vrai serveur web pour la "prod" (Apache pour les fichiers statiques + 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)
* DOC:
* TESTS:
* Unit tests
* Functional tests (with Celery and simulators)
* LAUNCH:
* Start simulators
* Start Celery
* Start pyros
* USE:
* Administration of the database: http://localhost:8000/admin
* Interacting with Pyros: http://localhost:8000 :
* Watch the environment: devices, weather, site
* Watch the data processing: images,
* submit a Routine Request: routines
---
h2. %{margin-left:0px; font-weight:bold; font-size:25px; display:block; color:red;}Applications tasks%
h3. Dashboard
* Create the backoffice views as the modules are integrated in pyros
* Think about a system of permissions
h3. Scheduler
* views
* Link the main page to the current schedule instead of the simulation page
* Show 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
* 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 computing
* Quotas evolution
* Blank space filling
* At the end of a scheduling send, it to the IC ?
h3. Alert Manager
* Web :
* Print if there is an alert in progress in the main page
* Link 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 objects
* Use strategies to build a request
* Possibility to change the default strategy
* Handle VOEvent updates
* Be careful to not create 2 alerts for a same GRB, seen by 2 different satellites
h3. Analyzer
* Apply the calibrations in the right function
* Apply the analyses only if it's a GRB
* Implement the analyses
* Send analyses to FSC
h3. Majordome
* TaskManager
* When a sequence is cancelled, give back the quota to the user
* In 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 launched
* Remove the default countdown (1, for tests)
* system_pause
* Abort the isntruments
* Stop the execution tasks
* system_restart
* Start a scheduling
* change_obs_conditions
* Change sequences status (if needed)
* If some status changed, re-launch a scheduling
h3. Monitoring
* views
* Move the dashboard here
* Print the instrument status
* Print 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 beginning
* Implement night start/end computation
* Initialize communication with the instruments
* Configure intruments at start
* Send software versions to the IC
* Initialize connection with PLC
* After the starting actions, loop to wait for the instruments configuration to be finished
* Ask PLC for status
* Ask filter wheel for status
* Store the instruments & PLC status
* Send all status to IC
* Analyse PLC status (obs conditions, ...)
* Create tasks of obs condition changes
h3. Observation Manager
* execute_plan :
* Use the cameras at a global level instead of creating them here (same for the filter wheels)
* Uncomment the instruments_ready waiting function
* Uncomment the observation_ending waiting function
* Try to remove code duplication
* Determine what needs to be done at the end of an observation
* create_calibrations :
* Make the calibration images
* Generate super images
* Send them to the IC
h3. 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 checks
* Add automatic computation of JD1/JD2
* Add checkbox for JD / GD
* Add options : copy my sequence on x days, and authorise report
* Add ETC-IS simulation
* Add 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 etc
* Uncomment filter for alerts removing
* When submitting, use the monitoring to determine sequences status
* When submitting, modify the first_schedule to False, when scheduling
* When unsubmitting, uncomment the check for EXED and EXING removing
* When unsubmitting, uncomment the scheduling and change the first_schedule to False
h3. User Manager
* Password recovery
* Profile page
* User validation by administrator / commission
* Handle permissions and access
h3. Common
* Network communication for every instrument
* Change the 'first_schedule' to False at the end of RequestBuilder.validate()
List of tasks by application, and general tasks (organization, tools, ...)
{{>toc}}
---
h2. %{margin-left:0px; font-weight:bold; font-size:25px; display:block; color:red;}General tasks%
* DJANGO :
* Upgrade to Django 1.10
* Remplacer le serveur web de "dev" (manage runserver) par un vrai serveur web pour la "prod" (Apache pour les fichiers statiques + 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)
* DOC:
* TESTS:
* Unit tests
* Functional tests (with Celery and simulators)
* LAUNCH:
* Start simulators
* Start Celery
* Start pyros
* USE:
* Administration of the database: http://localhost:8000/admin
* Interacting with Pyros: http://localhost:8000 :
* Watch the environment: devices, weather, site
* Watch the data processing: images,
* submit a Routine Request: routines
---
h2. %{margin-left:0px; font-weight:bold; font-size:25px; display:block; color:red;}Applications tasks%
h3. Dashboard
* Create the backoffice views as the modules are integrated in pyros
* Think about a system of permissions
h3. Scheduler
* views
* Link the main page to the current schedule instead of the simulation page
* Show 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
* 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 computing
* Quotas evolution
* Blank space filling
* At the end of a scheduling send, it to the IC ?
h3. Alert Manager
* Web :
* Print if there is an alert in progress in the main page
* Link 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 objects
* Use strategies to build a request
* Possibility to change the default strategy
* Handle VOEvent updates
* Be careful to not create 2 alerts for a same GRB, seen by 2 different satellites
h3. Analyzer
* Apply the calibrations in the right function
* Apply the analyses only if it's a GRB
* Implement the analyses
* Send analyses to FSC
h3. Majordome
* TaskManager
* When a sequence is cancelled, give back the quota to the user
* In 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 launched
* Remove the default countdown (1, for tests)
* system_pause
* Abort the isntruments
* Stop the execution tasks
* system_restart
* Start a scheduling
* change_obs_conditions
* Change sequences status (if needed)
* If some status changed, re-launch a scheduling
h3. Monitoring
* views
* Move the dashboard here
* Print the instrument status
* Print 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 beginning
* Implement night start/end computation
* Initialize communication with the instruments
* Configure intruments at start
* Send software versions to the IC
* Initialize connection with PLC
* After the starting actions, loop to wait for the instruments configuration to be finished
* Ask PLC for status
* Ask filter wheel for status
* Store the instruments & PLC status
* Send all status to IC
* Analyse PLC status (obs conditions, ...)
* Create tasks of obs condition changes
h3. Observation Manager
* execute_plan :
* Use the cameras at a global level instead of creating them here (same for the filter wheels)
* Uncomment the instruments_ready waiting function
* Uncomment the observation_ending waiting function
* Try to remove code duplication
* Determine what needs to be done at the end of an observation
* create_calibrations :
* Make the calibration images
* Generate super images
* Send them to the IC
h3. 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 checks
* Add automatic computation of JD1/JD2
* Add checkbox for JD / GD
* Add options : copy my sequence on x days, and authorise report
* Add ETC-IS simulation
* Add 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 etc
* Uncomment filter for alerts removing
* When submitting, use the monitoring to determine sequences status
* When submitting, modify the first_schedule to False, when scheduling
* When unsubmitting, uncomment the check for EXED and EXING removing
* When unsubmitting, uncomment the scheduling and change the first_schedule to False
h3. User Manager
* Password recovery
* Profile page
* User validation by administrator / commission
* Handle permissions and access
h3. Common
* Network communication for every instrument
* Change the 'first_schedule' to False at the end of RequestBuilder.validate()