# 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:**
  ```json
  { "cpuRequest": 2, "gpuLimit": 1, "gpuMem": 10000, "memoryLimit": "4Gi" }
  ```
- **Stored values (from API response):**
  ```json
  { "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:**
  ```yaml
  resources:
    cpuRequest: 4
    gpuLimit: 1
    gpuMem: 10000
    memoryLimit: "8Gi"
  model:
    huggingfaceName: "Qwen/Qwen2.5-0.5B-Instruct"
  ```
- **Stored values (parsed and stored in DB):**
  ```json
  { "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:**
  ```json
  { "cpuRequest": 4, "memoryLimit": "8Gi", "huggingfaceName": "Qwen/Qwen2.5-0.5B-Instruct" }
  ```
- **`valuesYaml` submitted:**
  ```yaml
  resources:
    cpuRequest: 2
    memoryLimit: "4Gi"
  model:
    huggingfaceName: "Qwen/Qwen2.5-7B-Instruct"
  ```
- **Stored values:**
  ```json
  { "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:**
  ```json
  { "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.