ocdp-go/docs/test2-values-priority.md

Test Report: values.yaml Override Priority

Date: 2026-05-11 Tester: test-user-c Cluster: dbf824f1-9962-4d8e-881e-870c75fdb6f5 Chart: charts/vllm-serve:0.6.0 Namespace: ocdp-u-test-c

---

Test Results

Method 1: values JSON field only (vllm-values-json)

• Deployment: ✅ Success (status: pending-install, no errors)
• Submitted values:

  { "cpuRequest": 2, "gpuLimit": 1, "gpuMem": 10000, "memoryLimit": "4Gi" }
  

• Stored values (from API response):

  { "cpuRequest": 2, "gpuLimit": 1, "gpuMem": 10000, "memoryLimit": "4Gi" }
  

• Result: Values were accepted and stored exactly as provided. No chart defaults were merged into the stored representation (e.g., shmSize: "8Gi" from chart defaults is absent).

Method 2: valuesYaml string field only (vllm-values-yaml)

• Deployment: ✅ Success (status: pending-install, no errors)
• Submitted valuesYaml:

  resources:
    cpuRequest: 4
    gpuLimit: 1
    gpuMem: 10000
    memoryLimit: "8Gi"
  model:
    huggingfaceName: "Qwen/Qwen2.5-0.5B-Instruct"
  

• Stored values (parsed and stored in DB):

  { "cpuRequest": 4, "gpuLimit": 1, "gpuMem": 10000, "memoryLimit": "8Gi" }
  

• Result: The YAML string was correctly parsed into the structured values field in the database. YAML parsing works correctly.

Method 3: Both values JSON AND valuesYaml with conflict (vllm-conflict-test)

• Deployment: ✅ Success (status: pending-install, no error or warning returned)
• values JSON submitted:

  { "cpuRequest": 4, "memoryLimit": "8Gi", "huggingfaceName": "Qwen/Qwen2.5-0.5B-Instruct" }
  

• valuesYaml submitted:

  resources:
    cpuRequest: 2
    memoryLimit: "4Gi"
  model:
    huggingfaceName: "Qwen/Qwen2.5-7B-Instruct"
  

• Stored values:

  { "cpuRequest": 4, "gpuLimit": 1, "gpuMem": 10000, "memoryLimit": "8Gi", "huggingfaceName": "Qwen/Qwen2.5-0.5B-Instruct" }
  

• Result: The values JSON field won every conflict. The valuesYaml values (cpuRequest: 2, memoryLimit: "4Gi", Qwen/Qwen2.5-7B-Instruct) were completely overridden by the values JSON values (cpuRequest: 4, memoryLimit: "8Gi", Qwen/Qwen2.5-0.5B-Instruct). No error or warning was presented to the user.

Method 4: No values (chart defaults, vllm-defaults-test)

• Deployment: ✅ Success (status: pending-install, no errors)
• Stored values:

  { "namespace": "ocdp-u-test-c" }
  

• Result: Only the auto-injected namespace was stored. Chart defaults (cpuRequest: 8, memoryLimit: "16Gi", etc.) are not stored in the API response — they are resolved at Helm deploy time.

---

Key Findings

1. Override Priority Order (when both fields provided)

Priority	Source	Description
Highest	values JSON field	Structured JSON object in the request body
Lowest	valuesYaml string field	Raw YAML string in the request body
Baseline	Chart built-in values.yaml	Default values packaged in the Helm chart

2. Conflict Resolution

When both values and valuesYaml are provided with conflicting values:

• values JSON wins — the structured JSON field takes priority over the YAML string
• No error or warning is returned to the user
• The system silently prefers the values JSON field

3. gpuMem=10000 Behavior

• The integer value 10000 was accepted without issues in both values JSON and valuesYaml formats
• No normalization or unit conversion was applied (stored as-is: 10000)
• Consistent with the project convention that nvidia.com/gpumem is treated as a vendor integer MB scalar

4. All values are stored in a unified values field in the DB

Both values JSON and valuesYaml inputs are converted to a single structured values JSON object in the database. The API response always returns the structured values field regardless of how the input was provided.

---

Recommendations

1. Document the priority order — users should know that when providing both values and valuesYaml, the values JSON field takes precedence and no error is raised.
2. Consider returning a warning when both fields are provided with conflicting values, as silent override could cause confusion.
3. The naming convention (values vs valuesYaml) can be misleading since both ultimately serve the same purpose. Consider deprecating one in the API to avoid ambiguity.