myxce/.kiro/specs/resource-distribution-mapping/requirements.md

7 lines
2 KiB
Markdown

# Requirements Document
## Project Description (Input)
Map resources.yaml's `resourcemap` field (per-host static/dynamic resource value assignments) through to the controller. Currently xcecommon.mapping._build_resource cannot map it because controller.capnp's Resource struct has its distributions/hostBased fields commented out (controller.capnp:208-209, corresponding to xce_resource_t's distributions/hbased_defined in include/xce/types.h). Scope: (1) design and un-comment/wire the capnp Resource.distributions (List(ResourceDistribution)) and Resource.hostBased fields, (2) regenerate generated capnp bindings, (3) implement xcecommon.mapping's YAML resourcemap -> capnp distributions/hostBased translation (YAML shape: list of {value, location: [hostnames]} entries -- see src/configs/resources.yaml for real examples covering dynamic hostbased, static shared, and static per-host-distinct resource patterns), (4) remove resourcemap from build.py's _UNMAPPED_BUT_VALID_ITEM_KEYS once mapped, (5) verify round-trip against the C side (res_distribution_t / xce_resource_t consumers, e.g. scheduler.c/worker.c resource distribution logic) to confirm the encoding actually matches what the C code expects at runtime, not just that it compiles. This is a real capnp schema change (adds wire-format fields) affecting the ClusterConfig contract other components already depend on -- needs design review, not a blind field un-comment.
## Requirements
<!-- BLOCKED: scope decision pending, see research.md -- do not generate requirements until one of the three candidate scopes there is chosen. Initial framing (a simple capnp-field-uncomment) understated the real scope once the C-side consumers were traced: the fields are dead end-to-end (not just uncommented capnp), a separate live per-host mechanism already exists via hosts.yaml, and two of the three plausible resourcemap semantics (shared pool, dynamic per-host reporting) require genuinely new controller/scheduler/worker runtime capability, not just a mapping fix. -->