api/config/v1: keep user-specified rename/devices for shared resources

[jonyhy96]

disableResoureRenaming currently resets the Rename and Devices fields of every entry under sharing.timeSlicing.resources (and sharing.mps.resources) to their defaults. That makes it impossible to:

• pin a shared resource to a specific subset of GPU UUIDs (per-UUID time-slicing), and
• expose two resource names on the same node, e.g. nvidia.com/gpu for full cards and nvidia.com/gpu.shared for the time-sliced subset.

Preserve both fields and emit a warning instead, so that user intent is honored. Downstream resource-manager code already supports per-UUID device lists and custom rename targets, so no additional plumbing is required.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[rajatchopra]

@jonyhy96 Can you provide a corresponding unit test case here? Possibly one that shows how two resource names are used within a node.

[jonyhy96]

@rajatchopra Thanks for the review! I've pushed a unit test TestDisableResoureRenamingKeepsUserSpec in api/config/v1/replicas_test.go (commit 85954f6) covering four cases:

1. Per-UUID rename preserved when renameByDefault=false.

2. Per-UUID devices list preserved when renameByDefault=true with the default rename target.

3. Two resource names on a single node — exactly the scenario you asked about: nvidia.com/gpu for full cards and nvidia.com/gpu.shared carrying only a UUID-selected subset (devices: ["GPU-"]). Any GPU on the node that isn't listed stays on the original nvidia.com/gpu resource name, so the two resource names coexist on the same node.

4. nil receiver no-op for defensive coverage.

All four sub-tests pass locally (go test ./api/config/v1/... is green). PTAL.