7f238a3168
- Add Workspace domain (entity, repository, service, handler, DTO) - Add multi-tenant K8s client with tenant binding and quota management - Add K8s diagnostics client (instance diagnostics) - Add authorization middleware (authz package) - Restructure frontend to feature-based architecture (features/) - Add User Management page in configuration - Add AccessDenied page and route guards - Refactor shared components (form inputs, layout, UI) - Update Tailwind config for new design system - Add comprehensive documentation (docs/, tasks/, plans) - Improve cluster service with better kubeconfig handling - Add tests for crypto, config, helm client, tenant binding
111 lines
4.5 KiB
Markdown
111 lines
4.5 KiB
Markdown
# 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.
|