Define the production workflow for weekly updates

[taldcroft]

Weekly cron processing will now generate a YAML file with suggestions for updates to the obs table.

After the ACA reviewer looks at the reports and the YAML file, possibly making edits, we need a mechanism for this YAML file to be incorporated into the processing.

Here are some considerations:

• Sunday: weekly job runs and generates an RC update to the supplement and possibly a YAML obs-status update (which is also a "candidate" for evaluation by ACA).
• Monday: ACA looks at the report and YAML. (Initially this will be the whole aspect team, but eventually just the ACA reviewer).
• ACA looks at the update and makes a couple of edits.
• One option: place the edited file in a defined location and start by hand an update process to incorporate the updates.
  • "By hand" would really need to be a dedicated task_schedule job so the processing gets logged into a known, standard location and doesn't depend on a persistent terminal session to complete.
  • Doing this means the update can be part of the promoted supplement for that week. Presumably the update output report needs to be reviewed.
  • Where does that update report live?
• Finally they perform some TBD process to schedule promotion for 2pm on the next Sunday.
  • Presumably that should happen before the standard weekly processing occurs, but I'm not 100% sure.

[taldcroft]

After more thought I updated the scope of this issue and substantially changed the description.

[javierggt]

The process, as I see it at this point is:

• Weekly run happens on Sunday. It produces:
  • a report with a nominal date of the following Monday (the run could happen any day, and the weekly date would still be the same).
  • a file called obs_status.yml in /proj/sot/ska/data/agasc/rc
• At some point during the week, ACA/reviewer looks into the failures and suspect IDs and edits obs_status.yml
• obs_status.yml is placed somewhere and the same command that was run on Sunday is scheduled to run again, adding --obs-status-file /path/to/obs_status.yml (issue Specifying report location when re-running agasc-update-magnitudes #90)
• This update does not have to be before the next update. What can happen if it is not before the next update is that one of the failures might appear again in the following weekly report.

[jeanconn]

I think we don't want to use the language "weekly run". I think we want to talk about the "candidate creation process" and the "promotion process" as separate events. The promotion process should happen on Sunday to work with other groups. The creation process could happen on Sunday (or later in the week if we don't need a full week for review).

[javierggt]

Based on some discussion, this is what I have in mind right now.

The process has three steps

• update magnitudes in candidate supplement
• decide about star-observation status
• promote supplement

Each step has a corresponding task schedule

• The task schedule for the update (first step) is the one already in the repository, with some changes.
• The schedule for the second step looks almost the same, but it is run only when required. There is no associated cronjob. The task itself would look like:

  <task agasc_supplement_update>
      cron       * * * * *
      check_cron * * * * *
      exec 1: agasc-supplement-update --log-level debug --output-dir $ENV{SKA}/data/agasc/rc --report --obs-status-file $ENV{SKA}/data/agasc/rc/obs_status.yml --args-file $ENV{SKA}/data/agasc/rc/supplement_reports/weekly/latest/call_args.yml
      exec 1: agasc-mag-estimate-report --output-dir $ENV{SKA}/data/agasc/rc
      exec 1: cp -fr $ENV{SKA}/data/agasc/rc/supplement_reports/weekly/latest/stars/* $ENV{SKA}/data/agasc/rc/supplement_reports/stars
  </task>
  

• The task schedule for the third step just copies files present in a prescribed location (say: $ENV{SKA}/data/agasc/promote) into $ENV{SKA}/data/agasc. It would be run weekly on a cron job.

From the perspective of an ACA reviewer

• The first step is automatic.
• The second step happens if the reviewer does this

  task_schedule3.pl -config task_schedule_obs_status.cfg
  

  or we could wrap it into a script, something like this

  agasc-promote-obs-status
  

• and the third step would be triggered by the reviewer doing the following (which copies files into $ENV{SKA}/data/agasc/promote)

  agasc-promote-supplement
  

[javierggt]

This issue has been closed. Workflow was defined here and implemented in PR #110. Some tweaks will be added in PR #112, but I am closing this.