[RHIDP-11653] Include Lightspeed By Default

[Jdubrick]

Description

• Moves Lightspeed to the main default compose.yaml
• Moves all Lightspeed configs/files to the root level /configs
  • Subsequently removed the /developer-lightspeed directory
• Disables the FAB plugin as it is conflicting with the Lightspeed FAB
  • I was told this is being removed anyway, so disabled for now with a comment
• Splits Lightspeed documentation into 2 pieces
  1. For users wanting to setup an LLM
  2. For maintainers wanting to update configs / plugin etc
• Updates CI tests as Lightspeed enabled by default so I removed the dedicated Lightspeed compose test
• Uses {{inherit}} for lightspeed plugin
  • Updated catalog index image to 1.10 to include lightspeed. Also resolves CI errors for other default plugins
• Adds nightly GH workflow to grab config changes for lightspeed
  • When release is cut we can update this to only check from the designated release branch to get any patch fixes

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

https://redhat.atlassian.net/browse/RHIDP-11653
https://redhat.atlassian.net/browse/RHIDP-11654

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

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (5) 📘 Rule violations (0) 📎 Requirement gaps (0)

Context used

✅ Tickets: RHIDP-11653

1. Sync push may fail 🐞 Bug ☼ Reliability ⭐ New

Description

The sync workflow pushes chore/sync-lightspeed-configs without --force when no open PR exists,
so if the remote branch already exists from a previously merged/closed PR, the push will be rejected
and the nightly job will fail. This will silently stop automated config syncing until someone
manually deletes the branch or reruns with changes.

Code

.github/workflows/sync-lightspeed-configs.yaml[R51-70]

+          TITLE="chore(lightspeed): sync config files from upstream"
+          BRANCH="chore/sync-lightspeed-configs"
+
+          EXISTING_PR=$(gh pr list --head "${BRANCH}" --state open --json number --jq '.[0].number // empty')
+
+          git checkout -b "${BRANCH}"
+
+          git add -A
+          if git diff --cached --quiet; then
+            echo "No staged changes to commit."
+            exit 0
+          fi
+          git commit -m "${TITLE}"
+
+          if [ -n "${EXISTING_PR}" ]; then
+            echo "Updating existing PR #${EXISTING_PR}."
+            git push --force origin "${BRANCH}"
+          else
+            git push origin "${BRANCH}"
+

Relevance

⭐⭐ Medium

No prior findings on gh-push/branch-exists; team does accept workflow reliability tweaks in CI files
(e.g., #48,#169).

PR-#48
PR-#169

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The workflow uses a fixed BRANCH name, only checks for an open PR, and performs a non-forced push
when no PR exists; this will fail if the branch exists remotely but has no open PR.

.github/workflows/sync-lightspeed-configs.yaml[51-70]

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 workflow uses a fixed branch name (`chore/sync-lightspeed-configs`) but only checks for an *open PR*, not whether the remote branch already exists. When no open PR exists, it does a normal `git push origin BRANCH`, which will fail if the branch already exists remotely (e.g., after a previous sync PR was merged/closed but the branch was not deleted).

## Issue Context
This is a scheduled nightly workflow; a persistent remote branch is a common situation and will cause recurring failures.

## Fix Focus Areas
- .github/workflows/sync-lightspeed-configs.yaml[51-88]

## Suggested fix
- Use `git checkout -B "${BRANCH}"` (reset-or-create) instead of `checkout -b`.
- Always push with `--force-with-lease` (or `--force`) to the fixed branch name, OR generate a unique branch name per run (e.g., include date) and close old PRs/branches.
- Optionally, detect remote branch existence via `git ls-remote --heads origin "${BRANCH}"` and delete/recreate or force-push accordingly.

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

---

2. rag-init shell command broken 🐞 Bug ☼ Reliability

Description

In compose.yaml, rag-init uses entrypoint ["/bin/sh","-c"] but passes a command string that
begins/ends with literal double quotes, so the shell treats the whole script as one quoted word and
fails to execute it. This causes rag-init to exit non-zero and blocks lightspeed-core (depends_on:
service_completed_successfully), leaving Lightspeed non-functional by default.

Code

compose.yaml[R83-91]

+    entrypoint: [ "/bin/sh", "-c" ]
+    command: |
+      "set -e; echo 'Copying RAG data...' && \
+      mkdir -p /data/vector_db /data/embeddings_model && \
+      cp -r /rag/vector_db/* /data/vector_db/ && \
+      cp -r /rag/embeddings_model/* /data/embeddings_model/ && \
+      chown -R 1001:0 /data/vector_db /data/embeddings_model || true && \
+      chmod -R a+rwX /data/vector_db /data/embeddings_model && \
+      echo 'Copy complete.'"

Relevance

⭐⭐⭐ High

Team historically accepts compose/runtime-breaking fixes (compose merge/healthcheck failures fixed
in PR #177; compose lint fixes PR #32).

PR-#177
PR-#32

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The command passed to /bin/sh -c starts with a literal " and ends with a literal ", which
makes the shell parse the entire script as a single token (a quoted word) instead of a sequence of
shell commands. Because lightspeed-core depends on rag-init completing successfully, this failure
prevents lightspeed-core from starting.

compose.yaml[74-127]
compose.yaml[94-107]

Agent prompt

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

### Issue description
`rag-init` sets `entrypoint: ["/bin/sh", "-c"]` but the `command: |` content is wrapped in literal double quotes. With `sh -c`, those quotes are part of the command string and cause the shell to interpret the entire multi-command script as one quoted word, so the init container fails and `lightspeed-core` never starts.

### Issue Context
This is now in the default `compose.yaml`, so it impacts every default install.

### Fix Focus Areas
- compose.yaml[74-92]

### Suggested fix
Remove the leading/trailing `"..."` from the `command` block and keep the script as plain shell, e.g.:
```yaml
entrypoint: ["/bin/sh", "-c"]
command: |
 set -e
 echo 'Copying RAG data...'
 mkdir -p /data/vector_db /data/embeddings_model
 cp -r /rag/vector_db/* /data/vector_db/
 cp -r /rag/embeddings_model/* /data/embeddings_model/
 chown -R 1001:0 /data/vector_db /data/embeddings_model || true
 chmod -R a+rwX /data/vector_db /data/embeddings_model
 echo 'Copy complete.'
```
(Keep the existing logic; only fix how it’s passed to `sh -c`.)

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

---

3. Invalid Lightspeed prompts YAML ✓ Resolved 🐞 Bug ≡ Correctness

Description

configs/app-config/app-config.yaml has lightspeed.prompts defined, but the list item is not
indented under prompts:, making the YAML invalid and preventing Backstage from loading the app
config. This can break RHDH startup (or at minimum fail to apply the Lightspeed configuration).

Code

configs/app-config/app-config.yaml[R256-263]

+lightspeed:
+  # OPTIONAL: Custom user prompts displayed in the Lightspeed UI
+  # These appear as suggested questions/prompts to help users get started
+  # If not provided, the plugin uses built-in default prompts
+  prompts:
+  - title: 'Getting Started with Red Hat Developer Hub'
+    message: Can you guide me through the first steps to start using Developer Hub as a developer, like exploring the Software Catalog and adding my service?
+

Relevance

⭐⭐⭐ High

Team fixes app-config changes that prevent startup (bad config/path fixes accepted in PR #83; config
precedence fixes PR #34).

PR-#83
PR-#34

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The - title: line is aligned with prompts: instead of being nested beneath it, which is invalid
YAML for a sequence value and will cause parsing errors when app-config is loaded.

configs/app-config/app-config.yaml[250-263]

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.prompts` YAML is malformed because the list items are not indented under the `prompts:` key. YAML parsers will reject this, and RHDH may fail to start or ignore the Lightspeed config.

### Issue Context
Current snippet:
```yaml
lightspeed:
 prompts:
 - title: ...
```

### Fix Focus Areas
- configs/app-config/app-config.yaml[256-263]

### Suggested fix
Indent the list under `prompts:`:
```yaml
lightspeed:
 prompts:
   - title: 'Getting Started with Red Hat Developer Hub'
     message: Can you guide me through ...
```

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

---

4. Misleading disable snippet 🐞 Bug ≡ Correctness ⭐ New

Description

The new commented block in dynamic-plugins.override.example.yaml says “Uncomment … to disable
Developer Lightspeed plugins”, but the file does not define an active plugins: key by default, so
uncommenting only that block produces invalid YAML. Users will likely follow the instruction
literally and break dynamic plugin config parsing.

Code

configs/dynamic-plugins/dynamic-plugins.override.example.yaml[R120-128]

+# # Uncomment the following to disable Developer Lightspeed plugins
+# # (also omit --profile lightspeed when starting RHDH Local)
+#   # Lightspeed frontend plugin
+#   - package: 'oci://registry.access.redhat.com/rhdh/red-hat-developer-hub-backstage-plugin-lightspeed:{{inherit}}'
+#     disabled: true
+#
+#   # Lightspeed backend plugin
+#   - package: 'oci://registry.access.redhat.com/rhdh/red-hat-developer-hub-backstage-plugin-lightspeed-backend:{{inherit}}'
+#     disabled: true

Relevance

⭐⭐⭐ High

Team frequently accepts fixes to dynamic-plugins override examples/comments for
correctness/usability (see accepted review feedback in #89).

PR-#89

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The file’s plugins: section is only shown as a commented example, and the new “uncomment to
disable” block provides list items without ensuring a plugins: key exists, making the instruction
unsafe to follow literally.

configs/dynamic-plugins/dynamic-plugins.override.example.yaml[10-16]
configs/dynamic-plugins/dynamic-plugins.override.example.yaml[120-128]

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 example override file does not include an active `plugins:` list by default (it’s commented out in the examples). The new “uncomment to disable Lightspeed” snippet adds list items but doesn’t include (or explicitly instruct to create) the required `plugins:` key, so users can easily create invalid YAML.

## Issue Context
This file is meant to be copied and edited by users; comments should be safe to uncomment as instructed.

## Fix Focus Areas
- configs/dynamic-plugins/dynamic-plugins.override.example.yaml[10-16]
- configs/dynamic-plugins/dynamic-plugins.override.example.yaml[120-128]

## Suggested fix
- Change the block to include the `plugins:` key in the same commented snippet, e.g.:
 ```yaml
 # plugins:
 #   - package: '...lightspeed...'
 #     disabled: true
 #   - package: '...lightspeed-backend...'
 #     disabled: true
 ```
- Or explicitly state “add these under your `plugins:` section” and ensure the indentation matches that structure.

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

---

5. SERVICE_HOST hardening undone 🐞 Bug ⛨ Security ⭐ New

Description

configs/extra-files/lightspeed-stack.yaml was changed to default-bind Lightspeed Core to
127.0.0.1, but compose.yaml overrides SERVICE_HOST back to 0.0.0.0, negating that hardening.
This makes the config inconsistent and removes the intended “bind to localhost by default” behavior.

Code

compose.yaml[120]

+      SERVICE_HOST: 0.0.0.0

Relevance

⭐⭐ Medium

Mixed security posture: some hardening suggestions rejected (e.g., compose hardening #177), so
SERVICE_HOST change acceptance unclear.

PR-#177

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

lightspeed-stack.yaml now defaults SERVICE_HOST to localhost, but compose.yaml explicitly overrides
it to 0.0.0.0 for the lightspeed-core container.

configs/extra-files/lightspeed-stack.yaml[16-21]
compose.yaml[118-121]

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 service config now defaults to binding on localhost (`127.0.0.1`) via `${env.SERVICE_HOST:=127.0.0.1}`, but the compose service explicitly sets `SERVICE_HOST: 0.0.0.0`, which overrides that default and defeats the intended hardening.

## Issue Context
Because `lightspeed-core` runs with `network_mode: service:rhdh`, binding to localhost should still be sufficient for in-namespace access (and aligns with the new default in `lightspeed-stack.yaml`).

## Fix Focus Areas
- compose.yaml[118-121]
- configs/extra-files/lightspeed-stack.yaml[16-21]

## Suggested fix
- Remove `SERVICE_HOST` from `compose.yaml` entirely and let `lightspeed-stack.yaml` default to `127.0.0.1`, OR set it to `127.0.0.1` in compose.
- Only allow `0.0.0.0` when there is a concrete need, and document that override.

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

---

6. CSP enables unsafe-eval 🐞 Bug ⛨ Security

Description

configs/app-config/app-config.yaml adds backend.csp.script-src with 'unsafe-eval', which weakens
CSP and increases impact of any XSS by allowing execution via eval/new Function. If this is only
needed for specific dev functionality, it should be gated/limited to avoid broad exposure.

Code

configs/app-config/app-config.yaml[R152-155]

+   script-src:
+     - "'self'"
+     - "'unsafe-eval'"
+     - "https://cdn.jsdelivr.net"

Relevance

⭐⭐ Medium

Repo previously allowed 'unsafe-eval' in Lightspeed app-config example (PR #125 era); no clear
precedent to forbid it.

PR-#125

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The CSP configuration explicitly permits 'unsafe-eval' in script-src, which relaxes the
browser’s script execution restrictions.

configs/app-config/app-config.yaml[142-155]

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 app-config CSP now includes `script-src: ['self', 'unsafe-eval', ...]`. Allowing `unsafe-eval` meaningfully weakens CSP defenses.

### Issue Context
This may be required for certain Backstage features, but enabling it globally should be an explicit, justified tradeoff.

### Fix Focus Areas
- configs/app-config/app-config.yaml[142-155]

### Suggested fix options
1. If not strictly required, remove `'unsafe-eval'`.
2. If required, add an explicit comment explaining why and consider scoping it (e.g., only in dev/local builds or via a separate optional local override config) so default installs can keep a stricter CSP when possible.

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

---

Previous review results

Review updated until commit a304a06

Results up to commit ca38de5

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. rag-init shell command broken 🐞 Bug ☼ Reliability

Description

In compose.yaml, rag-init uses entrypoint ["/bin/sh","-c"] but passes a command string that
begins/ends with literal double quotes, so the shell treats the whole script as one quoted word and
fails to execute it. This causes rag-init to exit non-zero and blocks lightspeed-core (depends_on:
service_completed_successfully), leaving Lightspeed non-functional by default.

Code

compose.yaml[R83-91]

+    entrypoint: [ "/bin/sh", "-c" ]
+    command: |
+      "set -e; echo 'Copying RAG data...' && \
+      mkdir -p /data/vector_db /data/embeddings_model && \
+      cp -r /rag/vector_db/* /data/vector_db/ && \
+      cp -r /rag/embeddings_model/* /data/embeddings_model/ && \
+      chown -R 1001:0 /data/vector_db /data/embeddings_model || true && \
+      chmod -R a+rwX /data/vector_db /data/embeddings_model && \
+      echo 'Copy complete.'"

Relevance

⭐⭐⭐ High

Team historically accepts compose/runtime-breaking fixes (compose merge/healthcheck failures fixed
in PR #177; compose lint fixes PR #32).

PR-#177
PR-#32

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The command passed to /bin/sh -c starts with a literal " and ends with a literal ", which
makes the shell parse the entire script as a single token (a quoted word) instead of a sequence of
shell commands. Because lightspeed-core depends on rag-init completing successfully, this failure
prevents lightspeed-core from starting.

compose.yaml[74-127]
compose.yaml[94-107]

Agent prompt

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

### Issue description
`rag-init` sets `entrypoint: ["/bin/sh", "-c"]` but the `command: |` content is wrapped in literal double quotes. With `sh -c`, those quotes are part of the command string and cause the shell to interpret the entire multi-command script as one quoted word, so the init container fails and `lightspeed-core` never starts.

### Issue Context
This is now in the default `compose.yaml`, so it impacts every default install.

### Fix Focus Areas
- compose.yaml[74-92]

### Suggested fix
Remove the leading/trailing `"..."` from the `command` block and keep the script as plain shell, e.g.:
```yaml
entrypoint: ["/bin/sh", "-c"]
command: |
 set -e
 echo 'Copying RAG data...'
 mkdir -p /data/vector_db /data/embeddings_model
 cp -r /rag/vector_db/* /data/vector_db/
 cp -r /rag/embeddings_model/* /data/embeddings_model/
 chown -R 1001:0 /data/vector_db /data/embeddings_model || true
 chmod -R a+rwX /data/vector_db /data/embeddings_model
 echo 'Copy complete.'
```
(Keep the existing logic; only fix how it’s passed to `sh -c`.)

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

---

2. Invalid Lightspeed prompts YAML ✓ Resolved 🐞 Bug ≡ Correctness

Description

configs/app-config/app-config.yaml has lightspeed.prompts defined, but the list item is not
indented under prompts:, making the YAML invalid and preventing Backstage from loading the app
config. This can break RHDH startup (or at minimum fail to apply the Lightspeed configuration).

Code

configs/app-config/app-config.yaml[R256-263]

+lightspeed:
+  # OPTIONAL: Custom user prompts displayed in the Lightspeed UI
+  # These appear as suggested questions/prompts to help users get started
+  # If not provided, the plugin uses built-in default prompts
+  prompts:
+  - title: 'Getting Started with Red Hat Developer Hub'
+    message: Can you guide me through the first steps to start using Developer Hub as a developer, like exploring the Software Catalog and adding my service?
+

Relevance

⭐⭐⭐ High

Team fixes app-config changes that prevent startup (bad config/path fixes accepted in PR #83; config
precedence fixes PR #34).

PR-#83
PR-#34

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The - title: line is aligned with prompts: instead of being nested beneath it, which is invalid
YAML for a sequence value and will cause parsing errors when app-config is loaded.

configs/app-config/app-config.yaml[250-263]

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.prompts` YAML is malformed because the list items are not indented under the `prompts:` key. YAML parsers will reject this, and RHDH may fail to start or ignore the Lightspeed config.

### Issue Context
Current snippet:
```yaml
lightspeed:
 prompts:
 - title: ...
```

### Fix Focus Areas
- configs/app-config/app-config.yaml[256-263]

### Suggested fix
Indent the list under `prompts:`:
```yaml
lightspeed:
 prompts:
   - title: 'Getting Started with Red Hat Developer Hub'
     message: Can you guide me through ...
```

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

---

3. CSP enables unsafe-eval 🐞 Bug ⛨ Security

Description

configs/app-config/app-config.yaml adds backend.csp.script-src with 'unsafe-eval', which weakens
CSP and increases impact of any XSS by allowing execution via eval/new Function. If this is only
needed for specific dev functionality, it should be gated/limited to avoid broad exposure.

Code

configs/app-config/app-config.yaml[R152-155]

+   script-src:
+     - "'self'"
+     - "'unsafe-eval'"
+     - "https://cdn.jsdelivr.net"

Relevance

⭐⭐ Medium

Repo previously allowed 'unsafe-eval' in Lightspeed app-config example (PR #125 era); no clear
precedent to forbid it.

PR-#125

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The CSP configuration explicitly permits 'unsafe-eval' in script-src, which relaxes the
browser’s script execution restrictions.

configs/app-config/app-config.yaml[142-155]

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 app-config CSP now includes `script-src: ['self', 'unsafe-eval', ...]`. Allowing `unsafe-eval` meaningfully weakens CSP defenses.

### Issue Context
This may be required for certain Backstage features, but enabling it globally should be an explicit, justified tradeoff.

### Fix Focus Areas
- configs/app-config/app-config.yaml[142-155]

### Suggested fix options
1. If not strictly required, remove `'unsafe-eval'`.
2. If required, add an explicit comment explaining why and consider scoping it (e.g., only in dev/local builds or via a separate optional local override config) so default installs can keep a stricter CSP when possible.

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

---

[rhdh-qodo-merge]

Review Summary by Qodo

(Agentic_describe updated until commit a304a06)

Include Lightspeed by Default in RHDH Local with Compose Profile

✨ Enhancement

Walkthroughs

Description

• Integrates Lightspeed into default RHDH Local installation via compose profile
• Moves Lightspeed configs from developer-lightspeed directory to root-level configs
• Disables FAB plugin due to conflict with Lightspeed FAB, marks as deprecated
• Splits Lightspeed documentation into user and maintainer guides
• Updates CI tests to remove dedicated Lightspeed compose test
• Adds nightly GitHub workflow for syncing upstream Lightspeed configs
• Updates plugin catalog index image to 1.10 to include Lightspeed support

Diagram

flowchart LR
  A["developer-lightspeed<br/>directory"] -->|consolidate| B["configs/extra-files<br/>root level"]
  C["Lightspeed compose<br/>services"] -->|integrate| D["compose.yaml<br/>with profile"]
  E["Separate docs"] -->|split| F["working-with-lightspeed.md<br/>maintaining-lightspeed.md"]
  G["CI tests"] -->|remove| H["dedicated Lightspeed<br/>compose test"]
  I["Nightly sync<br/>workflow"] -->|added| J["sync-lightspeed-configs.yaml"]
  D -->|enable with| K["--profile lightspeed<br/>flag"]

Loading

File Changes

1. compose.yaml ✨ Enhancement +61/-0

Add Lightspeed services with compose profile

compose.yaml

---

2. configs/app-config/app-config.yaml ✨ Enhancement +36/-1

Add Lightspeed plugin config and CSP settings

configs/app-config/app-config.yaml

---

3. configs/dynamic-plugins/dynamic-plugins.yaml ✨ Enhancement +13/-35

Add Lightspeed plugins, disable FAB plugin

configs/dynamic-plugins/dynamic-plugins.yaml

---

View more (20)

4. configs/dynamic-plugins/dynamic-plugins.override.example.yaml 📝 Documentation +10/-0

Add example for disabling Lightspeed plugins

configs/dynamic-plugins/dynamic-plugins.override.example.yaml

---

5. configs/extra-files/config.yaml ✨ Enhancement +38/-48

Update question validation prompts for broader scope

configs/extra-files/config.yaml

---

6. configs/extra-files/rhdh-profile.py ✨ Enhancement +47/-58

Revise system prompts and validation instructions

configs/extra-files/rhdh-profile.py

---

7. configs/extra-files/lightspeed-stack.yaml ✨ Enhancement +1/-1

Update service host configuration with env variable

configs/extra-files/lightspeed-stack.yaml

---

8. default.env ⚙️ Configuration changes +11/-2

Update catalog index image and add Lightspeed settings

default.env

---

9. wait-for-plugins-and-start.sh ✨ Enhancement +0/-6

Remove Lightspeed-specific config file handling

wait-for-plugins-and-start.sh

---

10. README.md 📝 Documentation +8/-3

Update startup commands and documentation references

README.md

---

11. .github/workflows/sync-lightspeed-configs.yaml ✨ Enhancement +88/-0

Add nightly workflow for syncing Lightspeed configs

.github/workflows/sync-lightspeed-configs.yaml

---

12. .github/workflows/test.yml 🧪 Tests +0/-2

Remove dedicated Lightspeed compose test

.github/workflows/test.yml

---

13. docs/lightspeed/working-with-lightspeed.md 📝 Documentation +360/-0

Add comprehensive user guide for Lightspeed setup

docs/lightspeed/working-with-lightspeed.md

---

14. docs/lightspeed/maintaining-lightspeed.md 📝 Documentation +96/-0

Add maintainer guide for Lightspeed architecture

docs/lightspeed/maintaining-lightspeed.md

---

15. mkdocs.yaml 📝 Documentation +2/-0

Add Lightspeed documentation to navigation

mkdocs.yaml

---

16. developer-lightspeed/README.md 📝 Documentation +0/-469

Remove old Lightspeed documentation file

developer-lightspeed/README.md

---

17. developer-lightspeed/compose.yaml ✨ Enhancement +0/-66

Remove separate Lightspeed compose file

developer-lightspeed/compose.yaml

---

18. developer-lightspeed/scripts/start-lightspeed.sh ✨ Enhancement +0/-92

Remove dedicated Lightspeed startup script

developer-lightspeed/scripts/start-lightspeed.sh

---

19. developer-lightspeed/scripts/stop-lightspeed.sh ✨ Enhancement +0/-132

Remove dedicated Lightspeed cleanup script

developer-lightspeed/scripts/stop-lightspeed.sh

---

20. developer-lightspeed/configs/app-config/app-config.lightspeed.local.example.yaml 📝 Documentation +0/-49

Remove Lightspeed-specific app config example

developer-lightspeed/configs/app-config/app-config.lightspeed.local.example.yaml

---

21. developer-lightspeed/configs/dynamic-plugins/dynamic-plugins.lightspeed.yaml ✨ Enhancement +0/-43

Remove separate Lightspeed plugins config

developer-lightspeed/configs/dynamic-plugins/dynamic-plugins.lightspeed.yaml

---

22. configs/extra-files/templates/placeholder.json Additional files +0/-0

...

configs/extra-files/templates/placeholder.json

---

23. scripts/sync-lightspeed-configs.sh Additional files +0/-0

...

scripts/sync-lightspeed-configs.sh

---

[Jdubrick]

Comment about rag init is not the case, functioning as expected.

[maysunfaisal]

IIRC UI team had an interest in the FAB pieces, previously we set it aside to merge the PR

[maysunfaisal]

generally lgtm

[Jdubrick]

/cc @karthikjeeyar

[karthikjeeyar]

Verified locally! Changes looks good to me. I have one small request to include notebook configuration.

[karthikjeeyar]

Even though it works, I have noticed this double slash in the embedding_model sentence-transformers//rag-content/embeddings_model, could you please fix this?

https://github.com/Jdubrick/rhdh-local/blob/bd3ac1d49709b1a0421df711d225bbb29326e13c/configs/extra-files/config.yaml#L192

[Jdubrick]

Even though it works, I have noticed this double slash in the embedding_model sentence-transformers//rag-content/embeddings_model, could you please fix this?

https://github.com/Jdubrick/rhdh-local/blob/bd3ac1d49709b1a0421df711d225bbb29326e13c/configs/extra-files/config.yaml#L192

@karthikjeeyar That unfortunately has to be there, the way Llama Stack references the embedding model since its mounted locally and not remote needs that for the pathing :/

[Jdubrick]

@karthikjeeyar I updated the config for notebooks. I think tests are failing because of changes to the default plugins (non lightspeed)

@JslYoon can you confirm the config I added?

[rm3l]

Since main should point to a stable GA release of RHDH, this PR should target the release-1.10 branch first (once it is created), and only be cherry-picked to main once 1.10 is out.

/hold

[Jdubrick]

Updated target to release-1.10

[rm3l]

We strive to avoid making users modify version-controlled files. Otherwise they might run into conflicts when pulling the latest changes.
To make the opt-out experience seamless, I'd suggest taking a look at Compose profiles and/or an env-var-driven approach (or any other approach that doesn't require modifying any version-controlled files).

[Jdubrick]

I added a lightspeed profile and updated the documentation / compose files to reflect it in this commit: 448555f

[rm3l]

It conflicts with Lightspeed FAB, but is this re-enabled if users disable Lightspeed ?

[Jdubrick]

@karthikjeeyar is it still the case that this plugin (global FAB) is being deprecated? I recall a thread in the UI Slack channel about it. If so, is the plan to keep it for 1.10 and workaround this conflict with Lightspeed, or is it removeable?

[karthikjeeyar]

Yes, it is removable. We discussed this with PMs earlier that we should stop using FAB and eventually remove it in 2.1 or later. FAB in rhdh-local contains a few links but most of it is already available global header's application launcher, so it is safe to remove from 1.10.

[Jdubrick]

I removed the pluginConfig to shorten to file down, but left it present as disabled. It is enabled by default in https://github.com/redhat-developer/rhdh/blob/main/default.packages.yaml#L20 so if I don't intentionally disable it, it could be present.

Ref commit: 51f7f72

[Jdubrick]

@rm3l marking this as a draft to make the changes you suggested as well as wait for the 1.10 release, since we need the catalog index updated to take advantage of the inherit

[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]

Persistent review updated to latest commit a304a06