[Release-1.10] chore: update lcore image from 0.5.3 to 0.6.2

[Jdubrick]

Target branch

• I have verified this PR targets the correct branch (see branching strategy)

Description

• Bumps LCORE image from 0.5.3 to 0.6.2 for RHDH 1.10.4 release as 0.5.x is going EOL

Which issue(s) does this PR fix or relate to

https://redhat.atlassian.net/browse/RHIDP-16122

PR acceptance criteria

• Tests updated and passing
• Documentation updated
• Built-in TechDocs updated if needed. Note that TechDocs changes may need to be reviewed by a Product Manager and/or Architect to ensure content accuracy, clarity, and alignment with user needs.

How to test changes / Special notes to the reviewer

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rhdh-qodo-merge]

PR Summary by Qodo

chore: bump Lightspeed Core image default to 0.6.2

⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Update the default Lightspeed Core (LCORE) container image tag from 0.5.3 to 0.6.2.
• Keep override behavior via LIGHTSPEED_CORE_IMAGE for local/custom deployments.

Diagram

graph TD
  A["compose.yaml"] --> B["Docker Compose"] --> C["lightspeed-core service"] --> D{{"quay.io image 0.6.2"}}
  C --> E["rhdh network (service:rhdh)"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Pin by immutable image digest

• ➕ Stronger supply-chain guarantees (avoids tag retargeting)
• ➕ Improves reproducibility across environments
• ➖ Harder to read/maintain than a semantic tag
• ➖ Requires a process to update digests regularly

2. Centralize the version in a single env/version file

• ➕ Reduces future diff churn across multiple compose/helm/manifests
• ➕ Easier to script/automate version bumps
• ➖ Adds indirection for a one-line change
• ➖ Only useful if multiple files reference the same image tag

3. Automate image bumping (Renovate/Dependabot for container tags)

• ➕ Consistent, frequent updates with less manual effort
• ➕ Can enforce policies (EOL, CVEs) automatically
• ➖ Additional tooling/config to maintain
• ➖ May create more frequent PR noise without good grouping rules

Recommendation: The PR’s direct compose.yaml tag bump is the simplest and appropriate change for this repo. If reproducibility/supply-chain control is a priority, consider digest pinning as a follow-up; otherwise keep the tagged default with the existing LIGHTSPEED_CORE_IMAGE override.

Files changed (1) +1 / -1

Other (1) +1 / -1

compose.yamlBump default lightspeed-core image tag to 0.6.2 +1/-1

Bump default lightspeed-core image tag to 0.6.2

• Updates the Docker Compose service definition to default to quay.io/lightspeed-core/lightspeed-stack:0.6.2 instead of 0.5.3. The existing environment-variable override mechanism remains unchanged.

compose.yaml

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 🔗 Cross-repo conflicts (1) 📜 Skill insights (0)

1. Stale Lightspeed image docs 🐞 Bug ⚙ Maintainability

Description

compose.yaml now defaults the Lightspeed Core image to 0.6.2, but the adjacent comment and
Lightspeed docs still reference older tags (0.5.1/0.6.0). This will mislead users when verifying
running containers or setting LIGHTSPEED_CORE_IMAGE overrides.

Code

compose.yaml[101]

+    image: ${LIGHTSPEED_CORE_IMAGE:-quay.io/lightspeed-core/lightspeed-stack:0.6.2} # dclint disable-line service-image-require-explicit-tag

Relevance

●●● Strong

Team often fixes stale compose/docs comments to keep user-facing guidance accurate after version
changes.

PR-#48
PR-#149

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The compose default image tag was updated to 0.6.2, but both the comment in compose.yaml and
multiple docs pages still mention older tags, proving a repo-internal inconsistency
introduced/worsened by this bump.

compose.yaml[96-101]
docs/lightspeed/maintaining-lightspeed.md[72-78]
docs/lightspeed/working-with-lightspeed.md[197-205]

Agent prompt

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

## Issue description
The Lightspeed Core image default was bumped to `0.6.2` in `compose.yaml`, but repo documentation and nearby comments still reference older image tags, creating inconsistent guidance.

## Issue Context
- The compose default is now `quay.io/lightspeed-core/lightspeed-stack:0.6.2`.
- The comment directly above the service still says the default is `0.5.1`.
- Lightspeed docs (`maintaining-lightspeed.md`, `working-with-lightspeed.md`) still show older tags (including an override example).

## Fix Focus Areas
- compose.yaml[96-101]
- docs/lightspeed/maintaining-lightspeed.md[72-78]
- docs/lightspeed/working-with-lightspeed.md[197-205]

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

---

2. LCS contract drift risk 🔗 Cross-repo conflict ☼ Reliability

Description

compose.yaml bumps the default lightspeed-core image to 0.6.2, which can drift from the Lightspeed
Core API/port contract assumed by the Intelligent Assistant backend in rhdh-plugins. Validate that
0.6.2 still serves on 127.0.0.1:8080 and supports the /v1/mcp-servers and /v1/vector-stores
endpoints used by the plugin, or coordinate required updates.

Code

compose.yaml[101]

+    image: ${LIGHTSPEED_CORE_IMAGE:-quay.io/lightspeed-core/lightspeed-stack:0.6.2} # dclint disable-line service-image-require-explicit-tag

Relevance

●● Moderate

They address breakages from image bumps, but cross-repo API contract validation may be deferred/not
actionable here.

PR-#205
PR-#177

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR changes the Lightspeed Core image tag used by rhdh-local. In rhdh-plugins, the Intelligent
Assistant backend hardcodes the Lightspeed Core host/port defaults (127.0.0.1:8080), constructs
lcsBaseUrl from those values, and calls /v1/mcp-servers and /v1/vector-stores—so any
Lightspeed Core image bump must preserve those contracts or be coordinated with rhdh-plugins
changes.

compose.yaml[96-129]
External repo: redhat-developer/rhdh-plugins, workspaces/intelligent-assistant/plugins/intelligent-assistant-backend/src/service/constant.ts [21-26]
External repo: redhat-developer/rhdh-plugins, workspaces/intelligent-assistant/plugins/intelligent-assistant-backend/src/service/router.ts [175-182]
External repo: redhat-developer/rhdh-plugins, workspaces/intelligent-assistant/plugins/intelligent-assistant-backend/src/service/router.ts [244-260]
External repo: redhat-developer/rhdh-plugins, workspaces/intelligent-assistant/plugins/intelligent-assistant-backend/src/service/notebooks/VectorStoresOperator.ts [133-156]

Agent prompt

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

## Issue description
`rhdh-local` now defaults to `quay.io/lightspeed-core/lightspeed-stack:0.6.2`. The `rhdh-plugins` Intelligent Assistant backend plugin assumes Lightspeed Core is reachable at `http://127.0.0.1:8080` and calls specific REST endpoints under `/v1`.

If Lightspeed Core 0.6.2 changes the listening port/host, removes/renames `/v1` endpoints, or changes the expected response shapes for those endpoints, `rhdh-local` will no longer be compatible with the pinned `rhdh-plugins` snapshot.

## Issue Context
This is a cross-repo integration contract between:
- **Provider**: Lightspeed Core container image configured in `rhdh-local` compose
- **Consumer**: `rhdh-plugins` Intelligent Assistant backend, which constructs `lcsBaseUrl` and calls `/v1/*` endpoints

## Fix Focus Areas
- compose.yaml[96-129]

### What to do
1. Smoke-test `rhdh-local` with IA enabled against Lightspeed Core `0.6.2`, specifically exercising:
  - `GET {lcsBaseUrl}/v1/mcp-servers`
  - `POST/GET {lcsBaseUrl}/v1/vector-stores`
2. If 0.6.2 is incompatible, choose one:
  - Update `rhdh-local` configuration (e.g., service port mapping/config) to match the new contract, and/or
  - Coordinate a corresponding update in `rhdh-plugins` (endpoint paths/semantics) and bump the plugin version used by the RHDH image/local setup.
3. If it is compatible, consider adding a short note (comment or docs) that `0.6.2` is the validated baseline for the IA plugin expectations.

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

---

Context

⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials

✅ Cross-repo context

  Explored: repo: redhat-developer/rhdh (sha: 88d4ad1d)

  Explored: repo: redhat-developer/rhdh-plugins (sha: 1f48dcf4)

Tip of the day

💡 Did you know, you can describe a rule in plain language on the Rules page and Qodo drafts it for you

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[rm3l]

/cherrypick main

[openshift-cherrypick-robot]

@rm3l: new pull request created: #293

Details

In response to this:

/cherrypick main

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[rm3l]

/cherrypick dev

[openshift-cherrypick-robot]

@rm3l: new pull request created: #296

Details

In response to this:

/cherrypick dev

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.