Loading decisions/0031-internal-field-names-mirror-srm-vocabulary.md +5 −6 Viewed Changes for decisions/0031-internal-field-names-mirror-srm-vocabulary.md: 5 added lines, 6 removed lines. Original line number Diff line number Diff line Loading @@ -99,12 +99,11 @@ Deferred or excluded: `service_order.source_protocol`. It fails this rule, but splitting it means defining the value vocabulary for both columns, which is a design decision rather than a naming fix. Tracked separately. - OEG's `SRMComputeIntent` diverges structurally from SRM's canonical `ComputeRequirements` (`srm.compute/v1`): `standalone` sits inside `compute` rather than at the top level; `cpu_millicores`, `memory_mb`, `topology` and `StorageVolume.mount_point` are optional in OEG and required in SRM; and OEG types as `str` several fields SRM types as enums (`AcceleratorType`, `InterfaceVisibility`, `TransportProtocol`, `RuntimeKind`). These are shape mismatches rather than naming, and are fixed separately. - OEG's `SRMComputeIntent` still diverges from SRM's canonical `ComputeRequirements` (`srm.compute/v1`) on remaining shape mismatches: `StorageVolume.mount_point` is optional in OEG and required in SRM, and OEG types as `str` several fields SRM types as enums (`AcceleratorType`, `InterfaceVisibility`, `TransportProtocol`, `RuntimeKind`). `cpu_millicores`, `memory_mb`, and `topology` are optional on both sides. - `SRMCapabilityRequirement.deployment_unit_ref` is retained. SRM's column is `deployment_unit_id`, but the catalog POST creates units and requirements in one transaction, so the requirement can only reference a unit that has no id yet. `ref` is an SRM column name Loading srm/canonical-parameters-schema.md +6 −3 Viewed Changes for srm/canonical-parameters-schema.md: 6 added lines, 3 removed lines. Original line number Diff line number Diff line Loading @@ -195,8 +195,10 @@ a defined canonical object rather than scattered columns. "schema_version": "srm.compute/v1", "compute": { "cpu_millicores": 2000, // CAMARA cpuPool.numCPU x1000 / GSMA numCPU "memory_mb": 2048, // CAMARA cpuPool.memory / GSMA memory "cpu_millicores": 2000, // CAMARA cpuPool.numCPU x1000 / GSMA numCPU; // omit when the northbound manifest has no CPU sizing "memory_mb": 2048, // CAMARA cpuPool.memory / GSMA memory; // omit when the northbound manifest has no memory sizing "accelerator": { // present only if GPU/VPU/FPGA required "type": "gpu", // gpu | vpu | fpga "units": 1, // CAMARA gpuPool.numGPU / GSMA numGPU Loading @@ -210,7 +212,8 @@ a defined canonical object rather than scattered columns. ] }, // placement/topology constraints (CAMARA topology.* / gpuPool.topology.*) // placement/topology constraints (CAMARA topology.* / gpuPool.topology.*); // omit the whole object when the northbound manifest has no topology "topology": { "min_nodes": 2, "min_node_cpu_millicores": 1000, Loading Loading
decisions/0031-internal-field-names-mirror-srm-vocabulary.md +5 −6 Viewed Changes for decisions/0031-internal-field-names-mirror-srm-vocabulary.md: 5 added lines, 6 removed lines. Original line number Diff line number Diff line Loading @@ -99,12 +99,11 @@ Deferred or excluded: `service_order.source_protocol`. It fails this rule, but splitting it means defining the value vocabulary for both columns, which is a design decision rather than a naming fix. Tracked separately. - OEG's `SRMComputeIntent` diverges structurally from SRM's canonical `ComputeRequirements` (`srm.compute/v1`): `standalone` sits inside `compute` rather than at the top level; `cpu_millicores`, `memory_mb`, `topology` and `StorageVolume.mount_point` are optional in OEG and required in SRM; and OEG types as `str` several fields SRM types as enums (`AcceleratorType`, `InterfaceVisibility`, `TransportProtocol`, `RuntimeKind`). These are shape mismatches rather than naming, and are fixed separately. - OEG's `SRMComputeIntent` still diverges from SRM's canonical `ComputeRequirements` (`srm.compute/v1`) on remaining shape mismatches: `StorageVolume.mount_point` is optional in OEG and required in SRM, and OEG types as `str` several fields SRM types as enums (`AcceleratorType`, `InterfaceVisibility`, `TransportProtocol`, `RuntimeKind`). `cpu_millicores`, `memory_mb`, and `topology` are optional on both sides. - `SRMCapabilityRequirement.deployment_unit_ref` is retained. SRM's column is `deployment_unit_id`, but the catalog POST creates units and requirements in one transaction, so the requirement can only reference a unit that has no id yet. `ref` is an SRM column name Loading
srm/canonical-parameters-schema.md +6 −3 Viewed Changes for srm/canonical-parameters-schema.md: 6 added lines, 3 removed lines. Original line number Diff line number Diff line Loading @@ -195,8 +195,10 @@ a defined canonical object rather than scattered columns. "schema_version": "srm.compute/v1", "compute": { "cpu_millicores": 2000, // CAMARA cpuPool.numCPU x1000 / GSMA numCPU "memory_mb": 2048, // CAMARA cpuPool.memory / GSMA memory "cpu_millicores": 2000, // CAMARA cpuPool.numCPU x1000 / GSMA numCPU; // omit when the northbound manifest has no CPU sizing "memory_mb": 2048, // CAMARA cpuPool.memory / GSMA memory; // omit when the northbound manifest has no memory sizing "accelerator": { // present only if GPU/VPU/FPGA required "type": "gpu", // gpu | vpu | fpga "units": 1, // CAMARA gpuPool.numGPU / GSMA numGPU Loading @@ -210,7 +212,8 @@ a defined canonical object rather than scattered columns. ] }, // placement/topology constraints (CAMARA topology.* / gpuPool.topology.*) // placement/topology constraints (CAMARA topology.* / gpuPool.topology.*); // omit the whole object when the northbound manifest has no topology "topology": { "min_nodes": 2, "min_node_cpu_millicores": 1000, Loading