From 84f2068ae3e72bdf0ff8656cfc064791ef38ed4d Mon Sep 17 00:00:00 2001 From: Rongsong Shen Date: Mon, 12 Oct 2026 09:57:37 +0000 Subject: [PATCH] docs(spec): application-profile: dispatch record covers resreq; removed profile makes jobs pend Co-Authored-By: Claude Opus 5.5 (1M context) --- .kiro/specs/application-profile/brief.md | 53 ++++++++++++++++++------ 1 file changed, 41 insertions(+), 12 deletions(-) diff --git a/.kiro/specs/application-profile/brief.md b/.kiro/specs/application-profile/brief.md index 11072282..a3aadb51 100644 --- a/.kiro/specs/application-profile/brief.md +++ b/.kiro/specs/application-profile/brief.md @@ -355,11 +355,20 @@ Not part of this spec, recorded here because they replace profile defaults: essentials, queue ceilings and project quotas still apply at submit. ### Dispatch record -Decided 2026-10-12 (user): execution-side values are **frozen at dispatch**. -- At each dispatch the controller reads the job's profile and puts the - effective execution values (mode, mode options, launch type, env, outer - pre/post-exec, limits) into the job's `start_info` for the worker, **and** - into an additive payload on the WAL dispatch fact +Decided 2026-10-12 (user): what a job was scheduled and started with is +**frozen at dispatch**. A pending job follows the current profile; a +dispatched job uses only its dispatch record until it is requeued or +restarted, and the scheduler no longer re-merges it. +- The record holds both sides: + - scheduling: the effective resreq (`select`, `rusage`, `span`, `same`, + `order`) and task count, so a running job's reservations (e.g. + `rusage[license=1]`) do not change when the profile changes, and are + rebuilt identically after a scheduler failover or restart; + - execution: mode, mode options, launch type, env, outer pre/post-exec, + limits. +- At each dispatch the controller puts the execution values into the job's + `start_info` for the worker, and the whole record into an additive + payload on the WAL dispatch fact (`persist_submit_job_dispatch_fact`, `controller/persist.c:8167`) and the snapshot. Both apply seams decode it; `/xce-audit-invariants` checks the round trip. @@ -371,6 +380,28 @@ Decided 2026-10-12 (user): execution-side values are **frozen at dispatch**. "profile changed since dispatch" when the current profile differs. - **Requeue or restart re-reads the profile** at the next dispatch, the same as the live merge does for pending jobs. +- Running jobs therefore need nothing from the live profile: post-exec at + the end, later remote tasks or a resize, and a service replica's probes + and in-place restarts all use the record. + +### Profile removed while jobs use it +Decided 2026-10-12 (user): **a job whose profile no longer exists pends**, +with the reason "application profile X is not defined". +- This applies to every job that reads the profile: pending jobs, requeued + or restarted jobs, and new service replicas (replacements, scale-up), + which are new jobs. Running jobs are unaffected (dispatch record); a + service whose profile is gone keeps its running replicas but shows as + degraded when one cannot be replaced. +- Putting the profile back releases the jobs. A rename is remove plus add. +- The removal is never refused (`xceadmin config build` works offline and + cannot know live jobs) and jobs never exit because of it. +- The controller's live-upgrade reply lists removed profiles still named by + pending jobs or services, with counts; `xceadmin config upgrade` prints + it. Needs a new scheduler pend reason (profile missing from + `Conf4Sched`). +- Leaning, for requirements: `jobmod --app ` moves a pending job to + another profile (the owner, with `app:use` on the new one; admins in bulk, + e.g. `--app-from `); the scheduler re-evaluates. - Why: for sandboxed jobs the mode and mounts a job actually ran with is a security/audit fact, and `job-sandbox-execution`'s mandatory cleanup depends on it; `persistence.md` does not allow memory-only state without a @@ -432,19 +463,17 @@ Decided 2026-10-12 (user): execution-side values are **frozen at dispatch**. - ~~How resource defaults combine with a job's own resreq~~ — settled 2026-10-09, owned by `job-config-merge`. - Profile versioning and audit. - - Whether the profile can be changed for a pending job (leaning yes: - re-check `app:use`, store the new name, the scheduler re-evaluates). + - `jobmod --app` for a pending job: who may, and the bulk form (leaning: + the owner with `app:use` on the new profile; admins in bulk). - Raised 2026-10-12, not yet decided: - - Removing a non-default profile that pending jobs still name (leaning: - xceadmin warns, the jobs pend with "profile X not defined", running - jobs continue). - A denylist of env variables a sandbox profile forbids jobs to add (e.g. `LD_PRELOAD`)? - Job labels (`--label key=value`, e.g. the preset name) and a summary grouped by label, to compare tuning variants: here, `job-status-detail-display`, or `xcecli-presets`? - - Settled 2026-10-12: execution values frozen at dispatch, re-read on - requeue ("Dispatch record"); override granularity (no markers; additive rule), + - Settled 2026-10-12: scheduling and execution values frozen at + dispatch, re-read on requeue ("Dispatch record"); a removed profile + makes its jobs pend ("Profile removed while jobs use it"); override granularity (no markers; additive rule), limits a job may lower (profile limits are maximums), personal presets (client side), `app:override` and inheritance (deferred). - Splitting the spec: execution mode, I/O directories, capability