Conversation
Part-of: #1780
runner/internal/shim/api/server.go
Outdated
| // Future API | ||
| r.AddHandler("GET", "/api/tasks", s.TaskListHandler) | ||
| r.AddHandler("GET", "/api/tasks/{id}", s.TaskInfoHandler) | ||
| r.AddHandler("PUT", "/api/tasks", s.TaskSubmitHandler) | ||
| r.AddHandler("POST", "/api/tasks/{id}/terminate", s.TaskTerminateHandler) | ||
| r.AddHandler("DELETE", "/api/tasks/{id}", s.TaskRemoveHandler) |
There was a problem hiding this comment.
Suggestion: switch from REST-like API to RPC (replace with POSTs) since it's more flexible for internal APIs and doesn't carry extra semantics.
| // | | | | ||
| // v v v | ||
| // terminated terminated terminated | ||
| // pending -> preparing -> pulling -> creating -> running -> terminated |
There was a problem hiding this comment.
@un-def, could you elaborate why preparing status is needed?
There was a problem hiding this comment.
The idea was to split Run() method into two — submission and run operations, Submit(), which should work as fast as possible, only puts a task into storage with pending status and returns an error on conflict, which is returned to the server via HTTP API. Run(), in turn, performs some preparation steps before it can start a container (puts authorized_keys, prepares volumes, etc.). Previously, these steps were executed with pending status (and with legacy API — pulling state), which is not quite right semantically.
In short, penging has not Run() yet, preparing — just first status in the Run() sequence (prepare, pull image, create container, run, mark terminated)
It's not a REST API anyway
Let's call it v2 Part-of: dstackai#1780
Let's call it v2 Part-of: dstackai#1780
Let's call it v2 Part-of: dstackai#1780
2 participants
/api/tasks{/...}errorinsteadboolor (bool,error) with error category (ErrNotFound,ErrInternal, etc.) wrapped.Routerstruct with a simpler interface addedPart-of: #1780