chore: update lightspeed core version for sprint 3293

[Jdubrick]

What does this PR do?:

• Updates Lightspeed Core version to track their latest as of June 10, 2026.
• Tested locally to make sure it is compatible with the current RAG image available

Which issue(s) this PR fixes:

N/A

PR acceptance criteria:

Testing and documentation do not need to be complete in order for this PR to be approved. We just need to ensure tracking issues are opened and linked to this PR, if they are not in the PR scope due to various constraints.

• Tested and Verified

• Documentation (READMEs, Product Docs, Blogs, Education Modules, etc.)

How to test changes / Special notes to the reviewer:

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0)

1. Llama Stack version mismatch 🐞 Bug ⚙ Maintainability

Description

images.yaml declares lightspeed-core targets Llama Stack 0.6.0, but the mounted Llama Stack config
still declares distro_name developer-lightspeed-lls-0.5.x, so the repo simultaneously signals two
different target Llama Stack versions for the same runtime. This conflicts with the documented
convention that lls-x.x denotes the Llama Stack version compatible with the configuration files.

Code

images.yaml[R17-18]

+  llama_version: 0.6.0
+  image: quay.io/lightspeed-core/lightspeed-stack:dev-20260610-be591ad

Evidence

The PR changes images.yaml to declare Llama Stack 0.6.0 for lightspeed-core, while the repo’s Llama
Stack config still declares an 0.5.x distro and is mounted/loaded into the same container, so the
runtime and repo metadata are inconsistent with the documented versioning convention.

images.yaml[16-21]
llama-stack-configs/config.yaml[16-18]
compose/compose.yaml[16-26]
lightspeed-core-configs/lightspeed-stack.yaml[24-27]
docs/RELEASE_PROCESS.md[5-8]

Agent prompt

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

## Issue description
`images.yaml` now declares `lightspeed-core.llama_version: 0.6.0`, but the Llama Stack config mounted into the container (`llama-stack-configs/config.yaml`) still advertises `distro_name: developer-lightspeed-lls-0.5.x`. This creates contradictory version metadata for the same runtime and conflicts with the repo’s release/versioning guidance.

## Issue Context
- `compose/compose.yaml` mounts `llama-stack-configs/config.yaml` into the `lightspeed-core` container at `/app-root/config.yaml`.
- `lightspeed-core-configs/lightspeed-stack.yaml` configures LCORE to load that file via `library_client_config_path`.
- `docs/RELEASE_PROCESS.md` defines `lls-x.x` as the Llama Stack version compatible with the configuration files.

## Fix Focus Areas
- images.yaml[16-18]
- llama-stack-configs/config.yaml[16-18]
- docs/RELEASE_PROCESS.md[5-8]
- compose/compose.yaml[16-26]
- lightspeed-core-configs/lightspeed-stack.yaml[24-27]

## What to change
1. Decide the intended target Llama Stack version for this repo snapshot.
2. Make the version metadata consistent by either:
  - updating `llama-stack-configs/config.yaml`’s `distro_name` (and any other version markers/config schema changes required for 0.6.x), or
  - adjusting `images.yaml` back to the version the checked-in configs are intended to support.
3. (Optional but recommended) If your process relies on it, update any related release metadata to match the new target version per `docs/RELEASE_PROCESS.md`.

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

---

[qodo-code-review]

PR Summary by Qodo

chore: bump Lightspeed Core image/version to 2026-06-10 build
⚙️ Configuration changes 🕐 Less than 5 minutes

Walkthroughs

Description

• Update Lightspeed Core container image reference to the latest June 10, 2026 build.
• Align images manifest metadata (llama_version + image tag) with the new Core version.

Diagram

graph TD
  A["env/default-values.env"] --> B["Runtime env vars"] --> C["Lightspeed Core image"]
  D["images.yaml"] --> E["Images manifest"] --> C
  C --> F[("Quay registry")]
  subgraph Legend
    direction LR
    _cfg["Config file"] ~~~ _rt["Runtime config"] ~~~ _img["Container image"] ~~~ _db[("Registry")]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Pin to a released semver tag (avoid dev-* tags)

• ➕ More reproducible builds and easier rollback/debugging
• ➕ Avoids surprise changes if a dev tag is rebuilt or moved
• ➖ May lag behind required fixes available only in dev snapshots
• ➖ Requires waiting for Core to cut a release

2. Automate image bumps via CI (scheduled PRs + validation)

• ➕ Consistent cadence with less manual work
• ➕ Can enforce smoke tests before merging
• ➖ Requires CI investment and test coverage that reliably validates compatibility
• ➖ May increase PR volume/noise if not tuned

Recommendation: Given the stated goal (track latest Core as of a specific date), updating the pinned image tag in both env defaults and the images manifest is the simplest and lowest-risk approach. If this pattern continues, consider moving to release tags for stability or adding a lightweight automated bump + smoke-test workflow to reduce manual tracking and catch incompatibilities earlier.

File Changes

Other (2)

default-values.env Bump LIGHTSPEED_CORE_IMAGE default to 2026-06-10 dev build +1/-1

Bump LIGHTSPEED_CORE_IMAGE default to 2026-06-10 dev build

• Updates the default Lightspeed Core container image tag from 0.5.1 to dev-20260610-be591ad so local/default deployments pull the newer Core build.

env/default-values.env

---

images.yaml Update lightspeed-core manifest (llama_version + image tag) +2/-2

Update lightspeed-core manifest (llama_version + image tag)

• Updates lightspeed-core metadata to llama_version 0.6.0 and points the image to dev-20260610-be591ad, keeping the manifest consistent with the env default.

images.yaml

---