[Webservice] Restructure database to give more meaningful success/failure information

Description

At present, the success/failure information we send to myMdC is unreliable in various important ways - see calibration/planning#104 . In addition, the correction_complete events sent via Kafka are sent per detector, but they don't actually tell you which detector they relate to (they give a detector type, such as JUNGFRAU, but not the Karabo ID of a specific detector). Replacing the webservice still looks like a big enough job that it seemed worth spending a bit of time improving the old one. I hope this might also ease the transition to the new one when it's ready.

The jobs database is completely redesigned, with three tables instead of one: each request from myMdC can have several executions, each of which can have several slurm_jobs. I think these terms line up with what Robert is using in Orca. I haven't tried to do any migration of existing data - we're only using it to track active jobs, so I'm assuming we'll just start with an empty database when deploying this change.

The jobs monitor code is also largely refactored, with the loop broken up into several methods in a JobsMonitor class.

How Has This Been Tested?

Deployed on max-exfl017, and submitted correction & dark requests from the test myMdC instance for the CALLAB proposal.

This revealed a number of previously hidden issues which are (hopefully) specific to CALLAB. The presence of JNGFR01 in the filenames triggers an execution for both FXE_XAD_JF1M and SPB_IRDA_JF4M, at least one of which will fail on any given run (as it can't find its data). Previously, the webservice would hide this, because the failing jobs would fail quickly, and the status would only come from the last jobs running, but with these changes the failures are visible.

Relevant Documents (optional)

https://in.xfel.eu/test_metadata/proposals/259/runs/63612

https://in.xfel.eu/test_metadata/proposals/259/runs/86193

https://in.xfel.eu/test_metadata/proposals/259#proposal-calibration

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactor (refactoring code with no functionality changes)

Checklist:

• My code follows the code style of this project.

Reviewers

@ahmedk @roscar @schmidtp

webservice/sqlite_view.py

@@ -2,12 +2,11 @@ import argparse
 import sqlite3
 
 parser = argparse.ArgumentParser(
-    description='Update run status at MDC for a given run id.')
+    description='Check jobs for a given proposal & run number')
 parser.add_argument('--sqlite-fpath', type=str, help='Path to sqlite file path',
-                    default='/home/xcal/calibration_webservice/webservice/webservice_jobs.sqlite')  # noqa
-parser.add_argument('--run', type=str, help='The run number required '
-                                            ' for checking its job status.')
-parser.add_argument('--proposal', type=str, help='Proposal numer')
+                    default='webservice_jobs.sqlite')
+parser.add_argument('--proposal', type=str, required=True, help='Proposal number')
+parser.add_argument('--run', type=int, required=True, help='Run number')
 
 args = vars(parser.parse_args())
 
@@ -16,11 +15,14 @@ proposal = args['proposal'].zfill(6)
 run = args['run']
 
 conn = sqlite3.connect(sqlite_fpath)
-c = conn.cursor()
 
-c.execute("SELECT * FROM jobs")
+c = conn.execute(
+    "SELECT status, elapsed, karabo_id, det_type, action FROM "
+    "slurm_jobs INNER JOIN executions USING (exec_id) "
+    "INNER JOIN requests USING (req_id) "
+    "WHERE proposal = ? AND run = ?",
+    (proposal, run)
+)
 
 for r in c.fetchall():
-    rid, jobid, db_proposal, db_run, status, time, _, _ = r
-    if db_proposal == proposal and db_run == run:
-        print(r)
+    print(r)