From 3442a57dd916109e044c8ba5797632134aea1f75 Mon Sep 17 00:00:00 2001 From: Rongsong Shen Date: Tue, 13 Oct 2026 07:17:22 +0000 Subject: [PATCH] docs(spec): project-config: a built-in default project always exists A job without a project and without a group default goes to the cluster default project, the built-in `default` (members all) unless configured otherwise; it is never rejected for lacking a project. Co-Authored-By: Claude Opus 5.5 (1M context) --- .kiro/specs/project-config/requirements.md | 7 ++++--- .kiro/steering/job-config-layering.md | 9 ++++++--- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/.kiro/specs/project-config/requirements.md b/.kiro/specs/project-config/requirements.md index c809f1cf..abab5baf 100644 --- a/.kiro/specs/project-config/requirements.md +++ b/.kiro/specs/project-config/requirements.md @@ -46,7 +46,7 @@ Discovery brief: `.kiro/specs/project-config/brief.md`. Governing rules: `.kiro/ **Decisions (2026-10-13, locations and visibility):** - A share may be owned at a location: `share: { at: { : { : amount } } }`, alongside amounts anywhere. Per resource, every host group named as a location forms its own pool, and all other hosts form the rest-of-cluster pool; pools are disjoint, a job's usage of a resource on a host is charged to that host's pool, and every pool follows the share rules on its own. An unlocated share therefore means "in the rest of the cluster". - A pool's capacity is the static total of the resource over its registered hosts, including hosts that are down or closed and excluding decommissioned ones; elastic hosts count once they have joined. -- A submit with no project and no applicable default is rejected (as today) with an error listing the user's projects. +- Every job gets a project: a built-in top-level project `default` always exists (members `all`, no share, so it draws from the root's unassigned part). An admin may define `default` explicitly to give it shares, admins or a description, but its members must stay `all`. A job with no project and no default-for match goes to the cluster default project, which is `default` unless configured otherwise (user, 2026-10-13, replacing "rejected with an error listing the user's projects"). - A per-user default project is a client-side setting (`xcecli` config or a preset, `xcecli-presets`), not server state. - Members of a project see the shares and usage of the project and all its ancestors, but not the members or per-user usage of sibling projects. @@ -117,7 +117,7 @@ This feature makes projects first-class cluster configuration entities that cont #### Acceptance Criteria 1. The configuration tool shall accept project definitions consisting of a path name, an optional description, members (user names, user-group names, or `all`), optional excluded members, optional admins (user names or user-group names), an optional list of user groups for which the project is the default, an optional `share` (a map from resource name to an absolute amount or a percentage of the parent's share, plus an optional `at` map from host-group name to such a resource map for shares owned at that location), an optional `member_quota` (a map from resource name to an absolute amount), and optional `aliases` (earlier path names of the project). The resource names include the built-in `jobs`. 2. The configuration tool shall treat a path name of one segment (e.g. `eng`) as a top-level project and a path of several `/`-separated segments (e.g. `eng/hpc/cfd`) as a child of the project named by the path without its last segment. -3. The configuration tool shall accept an optional cluster default project naming one defined project. +3. The configuration tool shall accept an optional cluster default project naming one defined project; when none is configured, the cluster default project is the built-in project `default`. 4. If a project definition repeats a path name, uses a reserved name, has an empty or malformed path segment, names a parent project that is not defined, names an undefined user group (in members, excluded members or admins), lists a default-for user group that is not covered by the project's members, has a `share` or `member_quota` entry naming an undeclared resource or giving a negative or non-numeric amount, has a percentage in `member_quota`, a percentage above 100% in `share`, or a percentage for `jobs`, names `jobs` under `at` or an undefined host group as a location, names for one resource two locations whose host groups share a host, declares a `share` for a resource in a pool (a location, or the rest of the cluster) in which its parent (when it has one) declares no share of that resource, gives siblings shares of one resource in one pool in different forms (absolute and percentage), or gives siblings shares in one pool that add up to more than 100% or, when all are absolute and the parent's is absolute, to more than the parent's share, then the configuration tool shall reject the configuration with an error identifying the project and the offending field. 5. If the cluster default project names an undefined project, or a project whose members do not include every user, then the configuration tool shall reject the configuration with an error naming the cluster default project. 6. When a configuration with changed project definitions is applied by live configuration upgrade, the Cluster shall apply the new definitions to all subsequent submissions and scheduling decisions without a restart. @@ -125,6 +125,7 @@ This feature makes projects first-class cluster configuration entities that cont 8. If the limit configuration contains a limit scoped to projects (listed or per project), then the configuration tool shall reject the configuration with an error naming the limit and stating that project shares are written on the project. 9. If an alias is malformed as a path, equals a defined project's path or another alias, names an alias (a chain), or is used as the cluster default project, a default-for target or a parent path, then the configuration tool shall reject the configuration with an error naming the project and the alias. 10. Where a project with members has children whose shares of a resource add up to its whole share, so that its unassigned part of that resource is empty, the configuration tool shall warn that jobs charged directly to that project can never get that resource. +11. The Cluster shall always have a top-level project `default` whose members are `all`, whether or not the configuration defines it; the configuration tool shall accept an explicit definition of `default` (description, admins, `share`, `member_quota`) and reject one whose members are not `all` or that has excluded members. ### Requirement 2: Project resolution at submit **Objective:** As a user, I want my job to get the right project when I do not name one, so that I do not have to pass `-P` for my usual project. @@ -132,7 +133,7 @@ This feature makes projects first-class cluster configuration entities that cont #### Acceptance Criteria 1. When a job is submitted with a project path name, the Cluster shall use that project for the job, whether it is a top-level, inner or leaf project. 2. When a job is submitted without a project name and at least one defined project lists a user group the submitter belongs to as default-for, the Cluster shall use the first such project in configuration order. -3. When a job is submitted without a project name and no default-for rule matches the submitter, the Cluster shall use the cluster default project if one is configured, and otherwise the project `default`; if, while projects are defined, that project is not defined, the Cluster shall reject the submission with an error stating that no project was given and no default applies, and listing the projects the user may submit under. +3. When a job is submitted without a project name and no default-for rule matches the submitter, the Cluster shall use the cluster default project (the built-in `default` unless another is configured), so a job submitted without a project is never rejected for lacking one. 4. The Cluster shall record the resolved project name on the job at submit, show it in the job's details, and keep it unchanged across later configuration changes, failover and restart. 5. The Cluster shall apply the same project resolution to every submission through the REST API (`xcecli` and any other client of the API) and to every element of a job array. 6. The Cluster shall identify a project at submit only by its full path name; a name that is only the last segment of a defined project's path (e.g. `cfd` for `eng/hpc/cfd`) is treated as the top-level project of that name. diff --git a/.kiro/steering/job-config-layering.md b/.kiro/steering/job-config-layering.md index 1caf643c..bef3c8ad 100644 --- a/.kiro/steering/job-config-layering.md +++ b/.kiro/steering/job-config-layering.md @@ -274,9 +274,12 @@ them: - **Visibility:** members see their project's and all ancestors' shares and usage (what their pend reasons refer to), not siblings' members or per-user usage. -- **Defaults:** no project given and no default applies → rejected with - the user's projects listed. A per-user default project is a client-side - `xcecli` setting or preset, not server state. +- **Defaults:** every job gets a project. A built-in top-level `default` + project always exists (members `all`; no share unless the admin defines + one). No `-P` → the user's group default (`default_for`) → the cluster + default project, which is `default` unless configured otherwise. A + per-user default project is a client-side `xcecli` setting or preset, + not server state. ## Convenience defaults are presets, not a level Apart from default reservations (the profile's `rusage` entries), tuning