(chore): update lightspeed configs

[rhdh-ai-envs-sync-bot]

PR Description

Automated sync triggered from redhat-ai-dev/lightspeed-configs@4e42f6ceb5b85b1fcc335cd7c8133b90f131d795.

Syncs llama-stack-config.yaml, lightspeed-stack-config.yaml, rhdh-profile.py, and charts/rhdh/values.yaml with the following image version:

• lightspeed-core: quay.io/lightspeed-core/lightspeed-stack:dev-20260710-2c3e52e

[Jdubrick]

/hold do not merge this. Changes need to be made ontop of this sync

[Jdubrick]

@HusneShabbir maybe you know more about the e2e tests here, it looks like a timeout but I don't have enough context to understand if it is because of these changes or not?

[Jdubrick]

@JslYoon @michael-valdron this PR is ready for review now

[qodo-code-review]

PR Summary by Qodo

Sync Lightspeed stack Helm configs and fix generated-config output path

⚙️ Configuration changes 🐞 Bug fix 🕐 20-40 Minutes

AI Description

• Sync Lightspeed/Llama Stack Helm configs to lightspeed-stack dev-20260710 image.
• Add a dedicated lightspeed-stack ConfigMap and mount it via values override.
• Prevent CI/runtime failures by writing generated config to /tmp and defaulting OPENAI_API_KEY.

Diagram

graph TD
  A["charts/rhdh/values.yaml"] --> B["Helm: rhdh chart"] --> C(["ConfigMap: lightspeed-stack-config"]) --> F["lightspeed-stack sidecar"] --> G["/tmp/.generated/run.yaml"]
  B --> D(["ConfigMap: llama-stack-config"]) --> F
  B --> E(["Secret: llama-stack-secrets"]) --> F

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Make OpenAI provider conditional in Helm

• ➕ Avoids needing a dummy OPENAI_API_KEY value like "passthrough"
• ➕ Reduces risk of accidentally enabling an OpenAI provider in environments that don’t intend to use it
• ➖ Adds Helm templating complexity and branching logic across config sources
• ➖ Requires clear enablement rules (values/env) and could drift from upstream synced configs

2. Write synthesized config to an explicit emptyDir mount

• ➕ More explicit than relying on container /tmp semantics
• ➕ Easy to reason about ownership/permissions and lifecycle
• ➖ Requires chart changes to add volumes/volumeMounts (slightly broader deployment impact)
• ➖ May be unnecessary if /tmp is already reliably writable in target environments

Recommendation: Current approach is reasonable for an automated config sync: introduce a dedicated ConfigMap for lightspeed-stack, pin the expected name via values, and redirect synthesized output to a known-writable path to avoid RO/permission issues. If "passthrough" becomes a concern operationally, consider the Helm-conditional OpenAI provider approach as a follow-up to fully disable OpenAI unless explicitly enabled.

Files changed (5) +65 / -33

Bug fix (1) +1 / -0

setup-secrets.shDefault OPENAI_API_KEY to a safe passthrough value +1/-0

Default OPENAI_API_KEY to a safe passthrough value

• Adds OPENAI_API_KEY to the generated llama-stack-secrets secret with a default of "passthrough" to avoid CI/runtime failures when OpenAI is present in config but not externally togglable.

scripts/setup-secrets.sh

Other (4) +64 / -33

CODEOWNERSAdd code ownership for new lightspeed-stack config template +1/-0

Add code ownership for new lightspeed-stack config template

• Adds CODEOWNERS coverage for the newly introduced lightspeed-stack-config Helm template to ensure correct reviewer routing for future changes.

.github/CODEOWNERS

lightspeed-stack-config.yamlNew ConfigMap template for lightspeed-stack.yaml +57/-0

New ConfigMap template for lightspeed-stack.yaml

• Introduces a new ConfigMap containing lightspeed-stack.yaml, including inference provider definitions (vLLM/OpenAI/sentence-transformers), cache/storage paths under /tmp, and MCP server configuration.

charts/rhdh/templates/lightspeed-stack-config.yaml

llama-stack-config.yamlRemove inference provider wiring from Llama Stack config +0/-31

Remove inference provider wiring from Llama Stack config

• Deletes the inference provider list previously embedded in the Llama Stack config, keeping provider configuration centralized in the lightspeed-stack config.

charts/rhdh/templates/llama-stack-config.yaml

values.yamlBump lightspeed-stack image and override ConfigMap + output args +6/-2

Bump lightspeed-stack image and override ConfigMap + output args

• Updates the sidecar image tag, adds args to write synthesized config to /tmp/.generated/run.yaml, and switches the stack ConfigMap entry to use a pre-created ConfigMap named lightspeed-stack-config.

charts/rhdh/values.yaml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 4 rules

1. Hardcoded Authorization header value ✗ Dismissed 📘 Rule violation ⛨ Security

Description

The new lightspeed-stack-config ConfigMap hardcodes an Authorization header value (client)
directly in a Kubernetes manifest rather than sourcing it from an approved secret mechanism, which
can embed credentials in Git and bypass the required secret-management flow. It also misaligns with
Backstage’s expected ${MCP_TOKEN} externalAccess token, so MCP tool calls from Lightspeed Core are
likely to fail authentication given the current secret wiring.

Code

charts/rhdh/templates/lightspeed-stack-config.yaml[R55-57]

+        url: 'http://localhost:7007/api/mcp-actions/v1'
+        authorization_headers:
+          Authorization: 'client'

Relevance

⭐⭐ Medium

Repo wires MCP_TOKEN via Kubernetes Secret; no prior examples of hardcoded Authorization headers in
ConfigMaps to compare.

PR-#37
PR-#48
PR-#51

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 902158 requires credentials to be managed via approved scripts and Kubernetes
Secrets and forbids inline secret-like literals in manifests; however,
charts/rhdh/templates/lightspeed-stack-config.yaml sets authorization_headers.Authorization to a
fixed value (client), embedding authentication material directly in repo-tracked YAML. Separately,
Backstage is configured to use ${MCP_TOKEN} as an externalAccess token for MCP clients, while
the Lightspeed sidecar is configured to load environment variables from llama-stack-secrets even
though MCP_TOKEN is created in a different secret (rhdh-secrets), demonstrating both the
configuration mismatch and why calls using the hardcoded header are likely to fail.

Rule 902158: Manage credentials only via approved scripts and Kubernetes secrets
charts/rhdh/templates/lightspeed-stack-config.yaml[55-57]
charts/rhdh/templates/lightspeed-stack-config.yaml[52-57]
charts/rhdh/values.yaml[361-369]
charts/rhdh/values.yaml[453-463]
charts/rhdh/values.yaml[567-570]
scripts/setup-secrets.sh[27-41]
scripts/setup-secrets.sh[81-90]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A Kubernetes manifest (`lightspeed-stack-config` ConfigMap) hardcodes an `Authorization` header (`client`) for MCP calls, which violates compliance requirements to manage credentials via approved scripts and Kubernetes Secrets and also does not match Backstage’s expected `${MCP_TOKEN}` externalAccess token, causing likely authentication failures for MCP tool invocations.

## Issue Context
The `authorization_headers.Authorization` value is authentication material and should not be embedded inline in a repo-tracked ConfigMap; it should be injected via environment variables sourced from a Kubernetes Secret created/managed by approved scripts (e.g., `scripts/setup-secrets.sh`) or referenced via `valueFrom`. Backstage registers `${MCP_TOKEN}` as an external access token (subject `mcp-clients`) and the Backstage Lightspeed plugin config also references `${MCP_TOKEN}` for MCP servers, but the Lightspeed sidecar currently reads env from `llama-stack-secrets` while `${MCP_TOKEN}` is stored under `rhdh-secrets`, so the client header and secret delivery must be aligned.

## Fix Focus Areas
- charts/rhdh/templates/lightspeed-stack-config.yaml[52-57]
- charts/rhdh/templates/lightspeed-stack-config.yaml[55-57]
- charts/rhdh/values.yaml[361-369]
- charts/rhdh/values.yaml[453-463]
- charts/rhdh/values.yaml[567-570]
- scripts/setup-secrets.sh[27-41]
- scripts/setup-secrets.sh[81-90]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Dummy OpenAI key stored ✗ Dismissed 🐞 Bug ☼ Reliability

Description

scripts/setup-secrets.sh now writes OPENAI_API_KEY=passthrough into llama-stack-secrets when
OPENAI_API_KEY is unset. Since the new Lightspeed stack config declares an OpenAI provider that
always reads OPENAI_API_KEY, any OpenAI-backed inference usage will likely fail with confusing
authentication errors due to the non-empty dummy credential.

Code

scripts/setup-secrets.sh[35]

+    --from-literal=OPENAI_API_KEY="${OPENAI_API_KEY:-passthrough}" \

Relevance

⭐⭐ Medium

No historical guidance on dummy/default secret literals in setup scripts; unclear if placeholders
are tolerated for optional providers.

PR-#80
PR-#192

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The script now injects OPENAI_API_KEY with a default literal value, and the new Lightspeed stack
config unconditionally includes an OpenAI provider that reads OPENAI_API_KEY from the environment.

scripts/setup-secrets.sh[27-41]
charts/rhdh/templates/lightspeed-stack-config.yaml[31-40]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
When `OPENAI_API_KEY` is not provided, the secrets setup script persists a literal fallback value (`passthrough`) into the Kubernetes secret. This can silently configure the OpenAI provider with an invalid credential and only fail later at request time.

## Issue Context
The Lightspeed stack config declares an OpenAI provider using `api_key_env: OPENAI_API_KEY`, so any non-empty fallback value will be treated as a real key.

## Fix Focus Areas
- scripts/setup-secrets.sh[27-41]
- charts/rhdh/templates/lightspeed-stack-config.yaml[31-40]

## Suggested fix
- Do not set `OPENAI_API_KEY` at all when it is unset (omit the `--from-literal=OPENAI_API_KEY=...` line conditionally), or set it to an empty string.
- Optionally, make the OpenAI provider conditional in `lightspeed-stack.yaml` (only include it when an enabling env var is set and a key is present).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[HusneShabbir]

@Jdubrick my PR for RHIDP-15130 (#237) is still pending merge because of the issues I highlighted in the Slack thread: https://redhat-internal.slack.com/archives/C08DZMUKU6R/p1783348719905989.

[michael-valdron]

lgtm

[Jdubrick]

@michael-valdron I will merge in the morning so I can monitor just in case