Add DB entity for task suite and agent#226
Conversation
Co-authored-by: BobAnkh <bobankhshen@gmail.com>
un-lock-able
force-pushed
the
task-suite-entity
branch
from
e872155 to
307a3ed
Compare
| // Timeout lives in the exec spec; default to 600s if unset/unparseable. | ||
| let timeout_secs = serde_json::from_value::<ExecSpec>(task.spec.clone()) | ||
| .ok() | ||
| .and_then(|s| s.timeout) | ||
| .map(|t| t.as_secs() as i64) | ||
| .unwrap_or(600); | ||
| // We allow a 60 seconds grace period | ||
| if TimeDateTimeWithTimeZone::now_utc() - task.updated_at | ||
| > time::Duration::seconds(task.timeout + 60) | ||
| > time::Duration::seconds(timeout_secs + 60) |
There was a problem hiding this comment.
Can we use some database query to avoid the serialization on our side? Can we just select the necessary columns from the db?
There was a problem hiding this comment.
The manual deserializing in this code is indeed redundent and the same functionality can be achieved using a sql query. However, this code mistakenly assumes that timeout is a int, which is not the actual case.
ExecSpec stores timeout as a humantime string, so the actual content is something that looks like {"timeout": "1m"}. If we were to keep using ExecSpec in both schema and database storage, we have to manually deserialize the time because sql cannot deserialize humantime strings into seconds.
Should I change this code to use humantime deserializing or shouldI create a struct different from ExecSpec in schema.rs that stores timeout as an int and store that into the database instead?
| // runner_uuid holds worker UUIDs, so map the worker ids to uuids. | ||
| let runner_uuid_subquery = Query::select() | ||
| .column((Worker::Entity, Worker::Column::WorkerId)) | ||
| .from(Worker::Entity) | ||
| .and_where( | ||
| Worker::Column::Id.in_subquery(worker_filter_subquery.clone()), | ||
| ) | ||
| .to_owned(); |
There was a problem hiding this comment.
This is copied from the impl-task-suite branch. Maybe we should discuss more on this.
There was a problem hiding this comment.
Then you should understand and check what it is, to see if it is necessary in our current implementation. I don't know if it suits your current impl.
2 participants
New entities
task_suites— a group-owned batch of tasks with priority, worker schedule, exec hooks, task counters, and aTaskSuiteState.agents— durable identity of a registered machine instance (not deleted on offline); tracks tags/labels, heartbeat, assigned suite, andAgentState.machines— physical machine code + metadata for an agent (1:1,Restrict).suite_agent_jobs— one attempt of an agent running a suite; per-suite job number, task counters,SuiteJobState, failure reason.hook_tasks— one provision/cleanup/background hook run in a job; has its own uuid, logs stored in sharedartifacts.task_suite_agent— links a suite to its candidate agents (how it was selected).group_agent— group→agent ACL row withGroupAgentRole, mirroringgroup_worker.New enums in
state.rs/role.rs:TaskSuiteState,AgentState,SuiteJobState,HookExecState,HookType,SelectionType,GroupAgentRole.Changes to existing rows
active_tasks/archived_tasks— add nullabletask_suite_id(FK,SetNull), propagated through the active→archived conversion.artifacts—task_idnow holds either a task uuid or a hook uuid.