skypilot-nightly 1.0.0.dev20250115__py3-none-any.whl → 1.0.0.dev20250117__py3-none-any.whl

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (33) hide show
  1. sky/__init__.py +2 -2
  2. sky/backends/cloud_vm_ray_backend.py +50 -67
  3. sky/cli.py +11 -34
  4. sky/core.py +8 -5
  5. sky/data/storage.py +66 -14
  6. sky/global_user_state.py +1 -1
  7. sky/jobs/constants.py +8 -7
  8. sky/jobs/controller.py +19 -22
  9. sky/jobs/core.py +0 -2
  10. sky/jobs/recovery_strategy.py +114 -143
  11. sky/jobs/scheduler.py +283 -0
  12. sky/jobs/state.py +257 -21
  13. sky/jobs/utils.py +338 -96
  14. sky/provision/kubernetes/instance.py +1 -1
  15. sky/resources.py +1 -1
  16. sky/serve/core.py +30 -5
  17. sky/serve/replica_managers.py +1 -3
  18. sky/skylet/constants.py +1 -1
  19. sky/skylet/events.py +7 -3
  20. sky/skylet/job_lib.py +10 -30
  21. sky/skylet/log_lib.py +8 -8
  22. sky/skylet/log_lib.pyi +3 -0
  23. sky/skylet/skylet.py +1 -1
  24. sky/templates/jobs-controller.yaml.j2 +7 -3
  25. sky/utils/kubernetes/deploy_remote_cluster.sh +5 -5
  26. sky/utils/resources_utils.py +25 -21
  27. sky/utils/subprocess_utils.py +48 -9
  28. {skypilot_nightly-1.0.0.dev20250115.dist-info → skypilot_nightly-1.0.0.dev20250117.dist-info}/METADATA +1 -1
  29. {skypilot_nightly-1.0.0.dev20250115.dist-info → skypilot_nightly-1.0.0.dev20250117.dist-info}/RECORD +33 -32
  30. {skypilot_nightly-1.0.0.dev20250115.dist-info → skypilot_nightly-1.0.0.dev20250117.dist-info}/LICENSE +0 -0
  31. {skypilot_nightly-1.0.0.dev20250115.dist-info → skypilot_nightly-1.0.0.dev20250117.dist-info}/WHEEL +0 -0
  32. {skypilot_nightly-1.0.0.dev20250115.dist-info → skypilot_nightly-1.0.0.dev20250117.dist-info}/entry_points.txt +0 -0
  33. {skypilot_nightly-1.0.0.dev20250115.dist-info → skypilot_nightly-1.0.0.dev20250117.dist-info}/top_level.txt +0 -0
sky/jobs/scheduler.py ADDED
@@ -0,0 +1,283 @@
1
+ """Scheduler for managed jobs.
2
+
3
+ Once managed jobs are submitted via submit_job, the scheduler is responsible for
4
+ the business logic of deciding when they are allowed to start, and choosing the
5
+ right one to start. The scheduler will also schedule jobs that are already live
6
+ but waiting to launch a new task or recover.
7
+
8
+ The scheduler is not its own process - instead, maybe_schedule_next_jobs() can
9
+ be called from any code running on the managed jobs controller instance to
10
+ trigger scheduling of new jobs if possible. This function should be called
11
+ immediately after any state change that could result in jobs newly being able to
12
+ be scheduled.
13
+
14
+ The scheduling logic limits the number of running jobs according to two limits:
15
+ 1. The number of jobs that can be launching (that is, STARTING or RECOVERING) at
16
+ once, based on the number of CPUs. (See _get_launch_parallelism.) This the
17
+ most compute-intensive part of the job lifecycle, which is why we have an
18
+ additional limit.
19
+ 2. The number of jobs that can be running at any given time, based on the amount
20
+ of memory. (See _get_job_parallelism.) Since the job controller is doing very
21
+ little once a job starts (just checking its status periodically), the most
22
+ significant resource it consumes is memory.
23
+
24
+ The state of the scheduler is entirely determined by the schedule_state column
25
+ of all the jobs in the job_info table. This column should only be modified via
26
+ the functions defined in this file. We will always hold the lock while modifying
27
+ this state. See state.ManagedJobScheduleState.
28
+
29
+ Nomenclature:
30
+ - job: same as managed job (may include multiple tasks)
31
+ - launch/launching: launching a cluster (sky.launch) as part of a job
32
+ - start/run: create the job controller process for a job
33
+ - schedule: transition a job to the LAUNCHING state, whether a new job or a job
34
+ that is already alive
35
+ - alive: a job controller exists (includes multiple schedule_states: ALIVE,
36
+ ALIVE_WAITING, LAUNCHING)
37
+ """
38
+
39
+ from argparse import ArgumentParser
40
+ import contextlib
41
+ from functools import lru_cache
42
+ import os
43
+ import time
44
+
45
+ import filelock
46
+ import psutil
47
+
48
+ from sky import sky_logging
49
+ from sky.jobs import constants as managed_job_constants
50
+ from sky.jobs import state
51
+ from sky.skylet import constants
52
+ from sky.utils import subprocess_utils
53
+
54
+ logger = sky_logging.init_logger('sky.jobs.controller')
55
+
56
+ # The _MANAGED_JOB_SCHEDULER_LOCK should be held whenever we are checking the
57
+ # parallelism control or updating the schedule_state of any job.
58
+ # Any code that takes this lock must conclude by calling
59
+ # maybe_schedule_next_jobs.
60
+ _MANAGED_JOB_SCHEDULER_LOCK = '~/.sky/locks/managed_job_scheduler.lock'
61
+ _ALIVE_JOB_LAUNCH_WAIT_INTERVAL = 0.5
62
+
63
+
64
+ @lru_cache(maxsize=1)
65
+ def _get_lock_path() -> str:
66
+ path = os.path.expanduser(_MANAGED_JOB_SCHEDULER_LOCK)
67
+ os.makedirs(os.path.dirname(path), exist_ok=True)
68
+ return path
69
+
70
+
71
+ def maybe_schedule_next_jobs() -> None:
72
+ """Determine if any managed jobs can be scheduled, and if so, schedule them.
73
+
74
+ Here, "schedule" means to select job that is waiting, and allow it to
75
+ proceed. It does NOT mean to submit a job to the scheduler.
76
+
77
+ For newly submitted jobs, scheduling means updating the state of the jobs,
78
+ and starting the job controller process. For jobs that are already alive but
79
+ are waiting to launch a new task or recover, just update the state of the
80
+ job to indicate that the launch can proceed.
81
+
82
+ This function transitions jobs into LAUNCHING on a best-effort basis. That
83
+ is, if we can start any jobs, we will, but if not, we will exit (almost)
84
+ immediately. It's expected that if some WAITING or ALIVE_WAITING jobs cannot
85
+ be started now (either because the lock is held, or because there are not
86
+ enough resources), another call to this function will be made whenever that
87
+ situation is resolved. (If the lock is held, the lock holder should start
88
+ the jobs. If there aren't enough resources, the next controller to exit and
89
+ free up resources should start the jobs.)
90
+
91
+ If this function obtains the lock, it will launch as many jobs as possible
92
+ before releasing the lock. This is what allows other calls to exit
93
+ immediately if the lock is held, while ensuring that all jobs are started as
94
+ soon as possible.
95
+
96
+ This uses subprocess_utils.launch_new_process_tree() to start the controller
97
+ processes, which should be safe to call from pretty much any code running on
98
+ the jobs controller instance. New job controller processes will be detached
99
+ from the current process and there will not be a parent/child relationship.
100
+ See launch_new_process_tree for more.
101
+ """
102
+ try:
103
+ # We must use a global lock rather than a per-job lock to ensure correct
104
+ # parallelism control. If we cannot obtain the lock, exit immediately.
105
+ # The current lock holder is expected to launch any jobs it can before
106
+ # releasing the lock.
107
+ with filelock.FileLock(_get_lock_path(), blocking=False):
108
+ while True:
109
+ maybe_next_job = state.get_waiting_job()
110
+ if maybe_next_job is None:
111
+ # Nothing left to start, break from scheduling loop
112
+ break
113
+
114
+ current_state = maybe_next_job['schedule_state']
115
+
116
+ assert current_state in (
117
+ state.ManagedJobScheduleState.ALIVE_WAITING,
118
+ state.ManagedJobScheduleState.WAITING), maybe_next_job
119
+
120
+ # Note: we expect to get ALIVE_WAITING jobs before WAITING jobs,
121
+ # since they will have been submitted and therefore started
122
+ # first. The requirements to launch in an alive job are more
123
+ # lenient, so there is no way that we wouldn't be able to launch
124
+ # an ALIVE_WAITING job, but we would be able to launch a WAITING
125
+ # job.
126
+ if current_state == state.ManagedJobScheduleState.ALIVE_WAITING:
127
+ if not _can_lauch_in_alive_job():
128
+ # Can't schedule anything, break from scheduling loop.
129
+ break
130
+ elif current_state == state.ManagedJobScheduleState.WAITING:
131
+ if not _can_start_new_job():
132
+ # Can't schedule anything, break from scheduling loop.
133
+ break
134
+
135
+ logger.debug(f'Scheduling job {maybe_next_job["job_id"]}')
136
+ state.scheduler_set_launching(maybe_next_job['job_id'],
137
+ current_state)
138
+
139
+ if current_state == state.ManagedJobScheduleState.WAITING:
140
+ # The job controller has not been started yet. We must start
141
+ # it.
142
+
143
+ job_id = maybe_next_job['job_id']
144
+ dag_yaml_path = maybe_next_job['dag_yaml_path']
145
+
146
+ # If the command line here is changed, please also update
147
+ # utils._controller_process_alive. `--job-id X` should be at
148
+ # the end.
149
+ run_cmd = (f'{constants.ACTIVATE_SKY_REMOTE_PYTHON_ENV};'
150
+ 'python -u -m sky.jobs.controller '
151
+ f'{dag_yaml_path} --job-id {job_id}')
152
+
153
+ logs_dir = os.path.expanduser(
154
+ managed_job_constants.JOBS_CONTROLLER_LOGS_DIR)
155
+ os.makedirs(logs_dir, exist_ok=True)
156
+ log_path = os.path.join(logs_dir, f'{job_id}.log')
157
+
158
+ pid = subprocess_utils.launch_new_process_tree(
159
+ run_cmd, log_output=log_path)
160
+ state.set_job_controller_pid(job_id, pid)
161
+
162
+ logger.debug(f'Job {job_id} started with pid {pid}')
163
+
164
+ except filelock.Timeout:
165
+ # If we can't get the lock, just exit. The process holding the lock
166
+ # should launch any pending jobs.
167
+ pass
168
+
169
+
170
+ def submit_job(job_id: int, dag_yaml_path: str) -> None:
171
+ """Submit an existing job to the scheduler.
172
+
173
+ This should be called after a job is created in the `spot` table as
174
+ PENDING. It will tell the scheduler to try and start the job controller, if
175
+ there are resources available. It may block to acquire the lock, so it
176
+ should not be on the critical path for `sky jobs launch -d`.
177
+ """
178
+ with filelock.FileLock(_get_lock_path()):
179
+ state.scheduler_set_waiting(job_id, dag_yaml_path)
180
+ maybe_schedule_next_jobs()
181
+
182
+
183
+ @contextlib.contextmanager
184
+ def scheduled_launch(job_id: int):
185
+ """Launch as part of an ongoing job.
186
+
187
+ A newly started job will already be LAUNCHING, and this will immediately
188
+ enter the context.
189
+
190
+ If a job is ongoing (ALIVE schedule_state), there are two scenarios where we
191
+ may need to call sky.launch again during the course of a job controller:
192
+ - for tasks after the first task
193
+ - for recovery
194
+
195
+ This function will mark the job as ALIVE_WAITING, which indicates to the
196
+ scheduler that it wants to transition back to LAUNCHING. Then, it will wait
197
+ until the scheduler transitions the job state, before entering the context.
198
+
199
+ On exiting the context, the job will transition to ALIVE.
200
+
201
+ This should only be used within the job controller for the given job_id. If
202
+ multiple uses of this context are nested, behavior is undefined. Don't do
203
+ that.
204
+ """
205
+
206
+ # If we're already in LAUNCHING schedule_state, we don't need to wait.
207
+ # This may be the case for the first launch of a job.
208
+ if (state.get_job_schedule_state(job_id) !=
209
+ state.ManagedJobScheduleState.LAUNCHING):
210
+ # Since we aren't LAUNCHING, we need to wait to be scheduled.
211
+ _set_alive_waiting(job_id)
212
+
213
+ while (state.get_job_schedule_state(job_id) !=
214
+ state.ManagedJobScheduleState.LAUNCHING):
215
+ time.sleep(_ALIVE_JOB_LAUNCH_WAIT_INTERVAL)
216
+
217
+ yield
218
+
219
+ with filelock.FileLock(_get_lock_path()):
220
+ state.scheduler_set_alive(job_id)
221
+ maybe_schedule_next_jobs()
222
+
223
+
224
+ def job_done(job_id: int, idempotent: bool = False) -> None:
225
+ """Transition a job to DONE.
226
+
227
+ If idempotent is True, this will not raise an error if the job is already
228
+ DONE.
229
+
230
+ The job could be in any terminal ManagedJobStatus. However, once DONE, it
231
+ should never transition back to another state.
232
+ """
233
+ if idempotent and (state.get_job_schedule_state(job_id)
234
+ == state.ManagedJobScheduleState.DONE):
235
+ return
236
+
237
+ with filelock.FileLock(_get_lock_path()):
238
+ state.scheduler_set_done(job_id, idempotent)
239
+ maybe_schedule_next_jobs()
240
+
241
+
242
+ def _set_alive_waiting(job_id: int) -> None:
243
+ """Should use wait_until_launch_okay() to transition to this state."""
244
+ with filelock.FileLock(_get_lock_path()):
245
+ state.scheduler_set_alive_waiting(job_id)
246
+ maybe_schedule_next_jobs()
247
+
248
+
249
+ def _get_job_parallelism() -> int:
250
+ # Assume a running job uses 350MB memory.
251
+ # We observe 230-300 in practice.
252
+ job_memory = 350 * 1024 * 1024
253
+ return max(psutil.virtual_memory().total // job_memory, 1)
254
+
255
+
256
+ def _get_launch_parallelism() -> int:
257
+ cpus = os.cpu_count()
258
+ return cpus * 4 if cpus is not None else 1
259
+
260
+
261
+ def _can_start_new_job() -> bool:
262
+ launching_jobs = state.get_num_launching_jobs()
263
+ alive_jobs = state.get_num_alive_jobs()
264
+ return launching_jobs < _get_launch_parallelism(
265
+ ) and alive_jobs < _get_job_parallelism()
266
+
267
+
268
+ def _can_lauch_in_alive_job() -> bool:
269
+ launching_jobs = state.get_num_launching_jobs()
270
+ return launching_jobs < _get_launch_parallelism()
271
+
272
+
273
+ if __name__ == '__main__':
274
+ parser = ArgumentParser()
275
+ parser.add_argument('--job-id',
276
+ required=True,
277
+ type=int,
278
+ help='Job id for the controller job.')
279
+ parser.add_argument('dag_yaml',
280
+ type=str,
281
+ help='The path to the user job yaml file.')
282
+ args = parser.parse_args()
283
+ submit_job(args.job_id, args.dag_yaml)
sky/jobs/state.py CHANGED
@@ -107,12 +107,25 @@ def create_table(cursor, conn):
107
107
  db_utils.add_column_to_table(cursor, conn, 'spot', 'local_log_file',
108
108
  'TEXT DEFAULT NULL')
109
109
 
110
- # `job_info` contains the mapping from job_id to the job_name.
111
- # In the future, it may contain more information about each job.
110
+ # `job_info` contains the mapping from job_id to the job_name, as well as
111
+ # information used by the scheduler.
112
112
  cursor.execute("""\
113
113
  CREATE TABLE IF NOT EXISTS job_info (
114
114
  spot_job_id INTEGER PRIMARY KEY AUTOINCREMENT,
115
- name TEXT)""")
115
+ name TEXT,
116
+ schedule_state TEXT,
117
+ controller_pid INTEGER DEFAULT NULL,
118
+ dag_yaml_path TEXT)""")
119
+
120
+ db_utils.add_column_to_table(cursor, conn, 'job_info', 'schedule_state',
121
+ 'TEXT')
122
+
123
+ db_utils.add_column_to_table(cursor, conn, 'job_info', 'controller_pid',
124
+ 'INTEGER DEFAULT NULL')
125
+
126
+ db_utils.add_column_to_table(cursor, conn, 'job_info', 'dag_yaml_path',
127
+ 'TEXT')
128
+
116
129
  conn.commit()
117
130
 
118
131
 
@@ -164,6 +177,9 @@ columns = [
164
177
  # columns from the job_info table
165
178
  '_job_info_job_id', # This should be the same as job_id
166
179
  'job_name',
180
+ 'schedule_state',
181
+ 'controller_pid',
182
+ 'dag_yaml_path',
167
183
  ]
168
184
 
169
185
 
@@ -189,16 +205,18 @@ class ManagedJobStatus(enum.Enum):
189
205
  SUCCEEDED -> SUCCEEDED
190
206
  FAILED -> FAILED
191
207
  FAILED_SETUP -> FAILED_SETUP
208
+ Not all statuses are in this list, since some ManagedJobStatuses are only
209
+ possible while the cluster is INIT/STOPPED/not yet UP.
192
210
  Note that the JobStatus will not be stuck in PENDING, because each cluster
193
211
  is dedicated to a managed job, i.e. there should always be enough resource
194
212
  to run the job and the job will be immediately transitioned to RUNNING.
213
+
195
214
  """
196
215
  # PENDING: Waiting for the jobs controller to have a slot to run the
197
216
  # controller process.
198
- # The submitted_at timestamp of the managed job in the 'spot' table will be
199
- # set to the time when the job is firstly submitted by the user (set to
200
- # PENDING).
201
217
  PENDING = 'PENDING'
218
+ # The submitted_at timestamp of the managed job in the 'spot' table will be
219
+ # set to the time when the job controller begins running.
202
220
  # SUBMITTED: The jobs controller starts the controller process.
203
221
  SUBMITTED = 'SUBMITTED'
204
222
  # STARTING: The controller process is launching the cluster for the managed
@@ -292,14 +310,66 @@ _SPOT_STATUS_TO_COLOR = {
292
310
  }
293
311
 
294
312
 
313
+ class ManagedJobScheduleState(enum.Enum):
314
+ """Captures the state of the job from the scheduler's perspective.
315
+
316
+ A newly created job will be INACTIVE. The following transitions are valid:
317
+ - INACTIVE -> WAITING: The job is "submitted" to the scheduler, and its job
318
+ controller can be started.
319
+ - WAITING -> LAUNCHING: The job controller is starting by the scheduler and
320
+ may proceed to sky.launch.
321
+ - LAUNCHING -> ALIVE: The launch attempt was completed. It may have
322
+ succeeded or failed. The job controller is not allowed to sky.launch again
323
+ without transitioning to ALIVE_WAITING and then LAUNCHING.
324
+ - ALIVE -> ALIVE_WAITING: The job controller wants to sky.launch again,
325
+ either for recovery or to launch a subsequent task.
326
+ - ALIVE_WAITING -> LAUNCHING: The scheduler has determined that the job
327
+ controller may launch again.
328
+ - LAUNCHING, ALIVE, or ALIVE_WAITING -> DONE: The job controller is exiting
329
+ and the job is in some terminal status. In the future it may be possible
330
+ to transition directly from WAITING or even INACTIVE to DONE if the job is
331
+ cancelled.
332
+
333
+ There is no well-defined mapping from the managed job status to schedule
334
+ state or vice versa. (In fact, schedule state is defined on the job and
335
+ status on the task.)
336
+ - INACTIVE or WAITING should only be seen when a job is PENDING.
337
+ - ALIVE_WAITING should only be seen when a job is RECOVERING, has multiple
338
+ tasks, or needs to retry launching.
339
+ - LAUNCHING and ALIVE can be seen in many different statuses.
340
+ - DONE should only be seen when a job is in a terminal status.
341
+ Since state and status transitions are not atomic, it may be possible to
342
+ briefly observe inconsistent states, like a job that just finished but
343
+ hasn't yet transitioned to DONE.
344
+ """
345
+ # The job should be ignored by the scheduler.
346
+ INACTIVE = 'INACTIVE'
347
+ # The job is waiting to transition to LAUNCHING for the first time. The
348
+ # scheduler should try to transition it, and when it does, it should start
349
+ # the job controller.
350
+ WAITING = 'WAITING'
351
+ # The job is already alive, but wants to transition back to LAUNCHING,
352
+ # e.g. for recovery, or launching later tasks in the DAG. The scheduler
353
+ # should try to transition it to LAUNCHING.
354
+ ALIVE_WAITING = 'ALIVE_WAITING'
355
+ # The job is running sky.launch, or soon will, using a limited number of
356
+ # allowed launch slots.
357
+ LAUNCHING = 'LAUNCHING'
358
+ # The controller for the job is running, but it's not currently launching.
359
+ ALIVE = 'ALIVE'
360
+ # The job is in a terminal state. (Not necessarily SUCCEEDED.)
361
+ DONE = 'DONE'
362
+
363
+
295
364
  # === Status transition functions ===
296
- def set_job_name(job_id: int, name: str):
365
+ def set_job_info(job_id: int, name: str):
297
366
  with db_utils.safe_cursor(_DB_PATH) as cursor:
298
367
  cursor.execute(
299
368
  """\
300
369
  INSERT INTO job_info
301
- (spot_job_id, name)
302
- VALUES (?, ?)""", (job_id, name))
370
+ (spot_job_id, name, schedule_state)
371
+ VALUES (?, ?, ?)""",
372
+ (job_id, name, ManagedJobScheduleState.INACTIVE.value))
303
373
 
304
374
 
305
375
  def set_pending(job_id: int, task_id: int, task_name: str, resources_str: str):
@@ -324,7 +394,7 @@ def set_submitted(job_id: int, task_id: int, run_timestamp: str,
324
394
  job_id: The managed job ID.
325
395
  task_id: The task ID.
326
396
  run_timestamp: The run_timestamp of the run. This will be used to
327
- determine the log directory of the managed task.
397
+ determine the log directory of the managed task.
328
398
  submit_time: The time when the managed task is submitted.
329
399
  resources_str: The resources string of the managed task.
330
400
  specs: The specs of the managed task.
@@ -458,13 +528,12 @@ def set_failed(
458
528
  with db_utils.safe_cursor(_DB_PATH) as cursor:
459
529
  previous_status = cursor.execute(
460
530
  'SELECT status FROM spot WHERE spot_job_id=(?)',
461
- (job_id,)).fetchone()
462
- previous_status = ManagedJobStatus(previous_status[0])
463
- if previous_status in [ManagedJobStatus.RECOVERING]:
464
- # If the job is recovering, we should set the
465
- # last_recovered_at to the end_time, so that the
466
- # end_at - last_recovered_at will not be affect the job duration
467
- # calculation.
531
+ (job_id,)).fetchone()[0]
532
+ previous_status = ManagedJobStatus(previous_status)
533
+ if previous_status == ManagedJobStatus.RECOVERING:
534
+ # If the job is recovering, we should set the last_recovered_at to
535
+ # the end_time, so that the end_at - last_recovered_at will not be
536
+ # affect the job duration calculation.
468
537
  fields_to_set['last_recovered_at'] = end_time
469
538
  set_str = ', '.join(f'{k}=(?)' for k in fields_to_set)
470
539
  task_str = '' if task_id is None else f' AND task_id={task_id}'
@@ -564,6 +633,44 @@ def get_nonterminal_job_ids_by_name(name: Optional[str]) -> List[int]:
564
633
  return job_ids
565
634
 
566
635
 
636
+ def get_schedule_live_jobs(job_id: Optional[int]) -> List[Dict[str, Any]]:
637
+ """Get jobs from the database that have a live schedule_state.
638
+
639
+ This should return job(s) that are not INACTIVE, WAITING, or DONE. So a
640
+ returned job should correspond to a live job controller process, with one
641
+ exception: the job may have just transitioned from WAITING to LAUNCHING, but
642
+ the controller process has not yet started.
643
+ """
644
+ job_filter = '' if job_id is None else 'AND spot_job_id=(?)'
645
+ job_value = (job_id,) if job_id is not None else ()
646
+
647
+ # Join spot and job_info tables to get the job name for each task.
648
+ # We use LEFT OUTER JOIN mainly for backward compatibility, as for an
649
+ # existing controller before #1982, the job_info table may not exist,
650
+ # and all the managed jobs created before will not present in the
651
+ # job_info.
652
+ with db_utils.safe_cursor(_DB_PATH) as cursor:
653
+ rows = cursor.execute(
654
+ f"""\
655
+ SELECT spot_job_id, schedule_state, controller_pid
656
+ FROM job_info
657
+ WHERE schedule_state not in (?, ?, ?)
658
+ {job_filter}
659
+ ORDER BY spot_job_id DESC""",
660
+ (ManagedJobScheduleState.INACTIVE.value,
661
+ ManagedJobScheduleState.WAITING.value,
662
+ ManagedJobScheduleState.DONE.value, *job_value)).fetchall()
663
+ jobs = []
664
+ for row in rows:
665
+ job_dict = {
666
+ 'job_id': row[0],
667
+ 'schedule_state': ManagedJobScheduleState(row[1]),
668
+ 'controller_pid': row[2],
669
+ }
670
+ jobs.append(job_dict)
671
+ return jobs
672
+
673
+
567
674
  def get_all_job_ids_by_name(name: Optional[str]) -> List[int]:
568
675
  """Get all job ids by name."""
569
676
  name_filter = ''
@@ -620,10 +727,12 @@ def get_latest_task_id_status(
620
727
  id_statuses = _get_all_task_ids_statuses(job_id)
621
728
  if not id_statuses:
622
729
  return None, None
623
- task_id, status = id_statuses[-1]
624
- for task_id, status in id_statuses:
625
- if not status.is_terminal():
626
- break
730
+ task_id, status = next(
731
+ ((tid, st) for tid, st in id_statuses if not st.is_terminal()),
732
+ id_statuses[-1],
733
+ )
734
+ # Unpack the tuple first, or it triggers a Pylint's bug on recognizing
735
+ # the return type.
627
736
  return task_id, status
628
737
 
629
738
 
@@ -670,6 +779,8 @@ def get_managed_jobs(job_id: Optional[int] = None) -> List[Dict[str, Any]]:
670
779
  for row in rows:
671
780
  job_dict = dict(zip(columns, row))
672
781
  job_dict['status'] = ManagedJobStatus(job_dict['status'])
782
+ job_dict['schedule_state'] = ManagedJobScheduleState(
783
+ job_dict['schedule_state'])
673
784
  if job_dict['job_name'] is None:
674
785
  job_dict['job_name'] = job_dict['task_name']
675
786
  jobs.append(job_dict)
@@ -721,3 +832,128 @@ def get_local_log_file(job_id: int, task_id: Optional[int]) -> Optional[str]:
721
832
  f'SELECT local_log_file FROM spot '
722
833
  f'WHERE {filter_str}', filter_args).fetchone()
723
834
  return local_log_file[-1] if local_log_file else None
835
+
836
+
837
+ # === Scheduler state functions ===
838
+ # Only the scheduler should call these functions. They may require holding the
839
+ # scheduler lock to work correctly.
840
+
841
+
842
+ def scheduler_set_waiting(job_id: int, dag_yaml_path: str) -> None:
843
+ """Do not call without holding the scheduler lock."""
844
+ with db_utils.safe_cursor(_DB_PATH) as cursor:
845
+ updated_count = cursor.execute(
846
+ 'UPDATE job_info SET '
847
+ 'schedule_state = (?), dag_yaml_path = (?) '
848
+ 'WHERE spot_job_id = (?) AND schedule_state = (?)',
849
+ (ManagedJobScheduleState.WAITING.value, dag_yaml_path, job_id,
850
+ ManagedJobScheduleState.INACTIVE.value)).rowcount
851
+ assert updated_count == 1, (job_id, updated_count)
852
+
853
+
854
+ def scheduler_set_launching(job_id: int,
855
+ current_state: ManagedJobScheduleState) -> None:
856
+ """Do not call without holding the scheduler lock."""
857
+ with db_utils.safe_cursor(_DB_PATH) as cursor:
858
+ updated_count = cursor.execute(
859
+ 'UPDATE job_info SET '
860
+ 'schedule_state = (?) '
861
+ 'WHERE spot_job_id = (?) AND schedule_state = (?)',
862
+ (ManagedJobScheduleState.LAUNCHING.value, job_id,
863
+ current_state.value)).rowcount
864
+ assert updated_count == 1, (job_id, updated_count)
865
+
866
+
867
+ def scheduler_set_alive(job_id: int) -> None:
868
+ """Do not call without holding the scheduler lock."""
869
+ with db_utils.safe_cursor(_DB_PATH) as cursor:
870
+ updated_count = cursor.execute(
871
+ 'UPDATE job_info SET '
872
+ 'schedule_state = (?) '
873
+ 'WHERE spot_job_id = (?) AND schedule_state = (?)',
874
+ (ManagedJobScheduleState.ALIVE.value, job_id,
875
+ ManagedJobScheduleState.LAUNCHING.value)).rowcount
876
+ assert updated_count == 1, (job_id, updated_count)
877
+
878
+
879
+ def scheduler_set_alive_waiting(job_id: int) -> None:
880
+ """Do not call without holding the scheduler lock."""
881
+ with db_utils.safe_cursor(_DB_PATH) as cursor:
882
+ updated_count = cursor.execute(
883
+ 'UPDATE job_info SET '
884
+ 'schedule_state = (?) '
885
+ 'WHERE spot_job_id = (?) AND schedule_state = (?)',
886
+ (ManagedJobScheduleState.ALIVE_WAITING.value, job_id,
887
+ ManagedJobScheduleState.ALIVE.value)).rowcount
888
+ assert updated_count == 1, (job_id, updated_count)
889
+
890
+
891
+ def scheduler_set_done(job_id: int, idempotent: bool = False) -> None:
892
+ """Do not call without holding the scheduler lock."""
893
+ with db_utils.safe_cursor(_DB_PATH) as cursor:
894
+ updated_count = cursor.execute(
895
+ 'UPDATE job_info SET '
896
+ 'schedule_state = (?) '
897
+ 'WHERE spot_job_id = (?) AND schedule_state != (?)',
898
+ (ManagedJobScheduleState.DONE.value, job_id,
899
+ ManagedJobScheduleState.DONE.value)).rowcount
900
+ if not idempotent:
901
+ assert updated_count == 1, (job_id, updated_count)
902
+
903
+
904
+ def set_job_controller_pid(job_id: int, pid: int):
905
+ with db_utils.safe_cursor(_DB_PATH) as cursor:
906
+ updated_count = cursor.execute(
907
+ 'UPDATE job_info SET '
908
+ 'controller_pid = (?) '
909
+ 'WHERE spot_job_id = (?)', (pid, job_id)).rowcount
910
+ assert updated_count == 1, (job_id, updated_count)
911
+
912
+
913
+ def get_job_schedule_state(job_id: int) -> ManagedJobScheduleState:
914
+ with db_utils.safe_cursor(_DB_PATH) as cursor:
915
+ state = cursor.execute(
916
+ 'SELECT schedule_state FROM job_info WHERE spot_job_id = (?)',
917
+ (job_id,)).fetchone()[0]
918
+ return ManagedJobScheduleState(state)
919
+
920
+
921
+ def get_num_launching_jobs() -> int:
922
+ with db_utils.safe_cursor(_DB_PATH) as cursor:
923
+ return cursor.execute(
924
+ 'SELECT COUNT(*) '
925
+ 'FROM job_info '
926
+ 'WHERE schedule_state = (?)',
927
+ (ManagedJobScheduleState.LAUNCHING.value,)).fetchone()[0]
928
+
929
+
930
+ def get_num_alive_jobs() -> int:
931
+ with db_utils.safe_cursor(_DB_PATH) as cursor:
932
+ return cursor.execute(
933
+ 'SELECT COUNT(*) '
934
+ 'FROM job_info '
935
+ 'WHERE schedule_state IN (?, ?, ?)',
936
+ (ManagedJobScheduleState.ALIVE_WAITING.value,
937
+ ManagedJobScheduleState.LAUNCHING.value,
938
+ ManagedJobScheduleState.ALIVE.value)).fetchone()[0]
939
+
940
+
941
+ def get_waiting_job() -> Optional[Dict[str, Any]]:
942
+ """Get the next job that should transition to LAUNCHING.
943
+
944
+ Backwards compatibility note: jobs submitted before #4485 will have no
945
+ schedule_state and will be ignored by this SQL query.
946
+ """
947
+ with db_utils.safe_cursor(_DB_PATH) as cursor:
948
+ row = cursor.execute(
949
+ 'SELECT spot_job_id, schedule_state, dag_yaml_path '
950
+ 'FROM job_info '
951
+ 'WHERE schedule_state in (?, ?) '
952
+ 'ORDER BY spot_job_id LIMIT 1',
953
+ (ManagedJobScheduleState.WAITING.value,
954
+ ManagedJobScheduleState.ALIVE_WAITING.value)).fetchone()
955
+ return {
956
+ 'job_id': row[0],
957
+ 'schedule_state': ManagedJobScheduleState(row[1]),
958
+ 'dag_yaml_path': row[2],
959
+ } if row is not None else None