lablup / lablup/backend.ai

Manager: record kernel status transitions into kernel_scheduling_history and apply from->to

Open
#12,785 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
670
Forks
183
Avg merge
15h 13m
Merged PRs (30d)
368

Description

Manager: on receiving KernelStatusTransitionAnycastEvent, record the transition into kernel_scheduling_history and apply from -> to (BEP-1061 section 3e).

The record maps the Agent's KernelStatus transition + result onto the table's phase/from_status/to_status/result/error_code/message columns. No new store is created; sub_steps stays for sokovan's own steps. Apply honors sokovan transition validation; retry/timeout/reschedule stay in sokovan. from_status lets the Manager reject a duplicate/stale transition idempotently.

Success Criteria:
- [ ] Transition event recorded into kernel_scheduling_history with correct column mapping
- [ ] Status applied only when sokovan validation passes; duplicate/stale transitions rejected idempotently
- [ ] Existing sokovan retry/reschedule paths unchanged
- [ ] pants test passes for affected packages

JIRA Issue: BA-6852

Contributor guide

Open the contributing guide

Research direction

Start by tracing Manager handling of KernelStatusTransitionAnycastEvent and the kernel_scheduling_history table mapping described in the issue. Check how sokovan validates transitions and preserves retry, timeout, and reschedule behavior. Done means recorded columns are correct, duplicate or stale transitions are rejected idempotently, and pants test passes for affected packages.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend, databases, distributed-systems
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.