feat(rack): add custom attributes to rack profiles

[jayzhudev]

Rack profiles currently provide predefined fields. They cannot carry optional key-value attributes/metadata that may be used to identify specific hardware variants or select workflows.

This PR adds attributes that can be configured at rack and component-role levels:

[rack_profiles.NVL72]
attributes = { attribute1 = "value1", additional_attribute2 = "value2" }

[rack_profiles.NVL72.rack_capabilities.compute]
attributes = { attribute1 = "compute-value" }

Attributes use the following precedence, from lowest to highest priority:

1. Rack-level attributes
2. Compute, switch, or power-shelf attributes
3. Predefined role, vendor, and product_family fields, overriding all custom values when names are identical

The value must be string typed. The vendor and product_family attributes do not populate the corresponding named rack-profile fields.

Related issues

Resolves #4146

Type of Change

• Add - New feature or capability
• Change - Changes in existing functionality
• Fix - Bug fixes
• Remove - Removed features or deprecated functionality
• Internal - Internal changes (refactoring, tests, docs, etc.)

Breaking Changes

• This PR contains breaking changes

Testing

• Unit tests added/updated
• Integration tests added/updated
• Manual testing performed
• No testing required (docs, internal refactor, etc.)

[coderabbitai]

Summary by CodeRabbit

• New Features

  • Added support for custom attributes on rack profiles and component roles.
  • Custom attributes are inherited from rack profiles and can be overridden by role-specific values.
  • Generated descriptor fields such as role, vendor, and product family take precedence over custom attributes.

• Bug Fixes

  • Added startup diagnostics for conflicting attribute definitions, helping identify overrides without preventing initialization.

Walkthrough

Changes

Rack profiles and compute, switch, and power-shelf capabilities now support custom attributes. Configuration merging preserves per-key provider precedence; RMS descriptors inherit rack and role attributes, generated fields take precedence, and startup emits structured collision warnings. Tests cover parsing, merging, validation, conversion boundaries, and RMS requests.

Rack profile attribute contracts

Layer / File(s)	Summary
Attribute models and parsing crates/api-model/src/rack_type.rs, crates/rpc/src/model/rack_type.rs	RackProfile and capability models add defaulted attribute maps; TOML parsing, duplicate keys, default values, and RPC exclusion behavior are tested.
Configuration fixtures and provider precedence crates/api-core/src/setup.rs, crates/api-core/src/tests/..., crates/api-core/tests/integration/expected_rack.rs	Configuration fixtures initialize the new fields, and tests verify per-key Figment provider precedence.
RMS descriptor inheritance crates/rack/src/rms_node_type.rs	Descriptor construction merges rack attributes, role attributes, and generated named fields in precedence order while preserving required-field validation.
Startup diagnostics and integration coverage crates/api-core/src/bootstrap.rs, crates/rack/src/rms_node_type.rs, crates/site-explorer/tests/integration/machine_creator.rs	Runtime prelude initialization invokes override diagnostics, and RMS request tests verify inherited and role-overridden attributes.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant ConfigProviders
  participant CarbideConfig
  participant RuntimePrelude
  participant RMSNodeDescriptor
  ConfigProviders->>CarbideConfig: merge rack profile attributes
  RuntimePrelude->>CarbideConfig: inspect rack profile overrides
  RuntimePrelude->>RuntimePrelude: emit structured warnings
  CarbideConfig->>RMSNodeDescriptor: provide rack and role attributes
  RMSNodeDescriptor->>RMSNodeDescriptor: apply generated field precedence

Loading

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: adding custom attributes to rack profiles.
Description check	✅ Passed	The description accurately matches the feature and its implementation details.
Linked Issues check	✅ Passed	The changes align with #4146 by adding attributes, merging them with precedence, flattening them into NodeDescriptor, and preserving validation.
Out of Scope Changes check	✅ Passed	No clear out-of-scope code changes are evident; the edits and added tests support the rack-attribute feature end to end.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

crates/rack/src/rms_node_type.rs (1)

182-224: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Extract shared vendor/product_family "presence" logic.

The trimmed, non-blank presence check for vendor and product_family here duplicates the identical rule already implemented in node_identity_for_profile (Lines 283-285 for vendor, Lines 272-276 for product family). If the blank-string definition ever changes in one spot, these warnings could silently misreport what the actual descriptor construction does.

♻️ Proposed shared helper

+fn present_str(value: Option<&str>) -> Option<&str> {
+    value.map(str::trim).filter(|value| !value.is_empty())
+}
+
 fn node_identity_for_profile(
     profile: &RackProfile,
     role: RmsNodeRole,
 ) -> Result<RmsNodeIdentity, NodeDescriptorError> {
-    let Some(product_family) = profile
-        .product_family
-        .as_ref()
-        .map(|family| family.as_str())
-        .filter(|family| !family.is_empty())
-    else {
+    let Some(product_family) = present_str(profile.product_family.as_ref().map(|f| f.as_str()))
+    else {
         return Err(NodeDescriptorError::MissingProductFamily);
     };

     let (vendor, role_attributes) = vendor_and_attributes_for_role(profile, role);

-    let Some(vendor) = vendor.map(str::trim).filter(|vendor| !vendor.is_empty()) else {
+    let Some(vendor) = present_str(vendor) else {
         return Err(NodeDescriptorError::VendorMissing { role: role.label() });
     };

             let named_attribute_keys = [
                 (KEY_ROLE, true),
-                (
-                    KEY_VENDOR,
-                    vendor
-                        .map(str::trim)
-                        .is_some_and(|vendor| !vendor.is_empty()),
-                ),
-                (
-                    KEY_PRODUCT_FAMILY,
-                    profile
-                        .product_family
-                        .as_ref()
-                        .is_some_and(|family| !family.as_str().is_empty()),
-                ),
+                (KEY_VENDOR, present_str(vendor).is_some()),
+                (
+                    KEY_PRODUCT_FAMILY,
+                    present_str(profile.product_family.as_ref().map(|f| f.as_str())).is_some(),
+                ),
             ];

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/rack/src/rms_node_type.rs` around lines 182 - 224, Extract the
trimmed, non-blank presence checks for vendor and product_family into a shared
helper or reusable presence logic, then reuse it in this named_attribute_keys
construction and node_identity_for_profile. Preserve the existing treatment of
missing, whitespace-only, and populated values so override warnings match
descriptor construction.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@crates/rack/src/rms_node_type.rs`:
- Around line 182-224: Extract the trimmed, non-blank presence checks for vendor
and product_family into a shared helper or reusable presence logic, then reuse
it in this named_attribute_keys construction and node_identity_for_profile.
Preserve the existing treatment of missing, whitespace-only, and populated
values so override warnings match descriptor construction.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 8ec53768-89fe-4db0-8819-e24afdc8874c

📥 Commits

Reviewing files that changed from the base of the PR and between 0ec89d3 and 9b8f268.

📒 Files selected for processing (8)

• crates/api-core/src/bootstrap.rs
• crates/api-core/src/setup.rs
• crates/api-core/src/tests/rack_state_controller/handler.rs
• crates/api-core/tests/integration/expected_rack.rs
• crates/api-model/src/rack_type.rs
• crates/rack/src/rms_node_type.rs
• crates/rpc/src/model/rack_type.rs
• crates/site-explorer/tests/integration/machine_creator.rs

[ajf]

NICo already has "config overload" (i.e. far too many configurations possible) - would this not be better served by APIs instead? Must they be config?

[jayzhudev]

NICo already has "config overload" (i.e. far too many configurations possible) - would this not be better served by APIs instead? Must they be config?

Agreed on the config overload. Right now rack profile is used as the source for NICo to RMS RPCs for hardware type resolution. In the short term, using rack profiles in the config seems to be more straightforward to the users compared to using APIs - the source config still needs to come from the operator. But yes, if the benefits are clear, we can move rack profiles to the DB and manage them via APIs in the future.