LCORE-2436: Update rag-content to generate lightspeed-stack config together with Llama Stack config#219
Conversation
…ck.yaml Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
… snippet Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…tegy to LCS config Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 44 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
WalkthroughThis PR adds Lightspeed Core Stack (LCS) configuration generation for BYOK RAG flows. It introduces new YAML templates for FAISS and PGVector backends, a ChangesLCS BYOK Configuration Generation
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Caller
participant LlamaStackDB as _LlamaStackDB
participant Disk
Caller->>LlamaStackDB: save()
LlamaStackDB->>LlamaStackDB: create vector store, update llama-stack.yaml
LlamaStackDB->>LlamaStackDB: write_lcs_config(provider_type, vector_store_id, db_path)
LlamaStackDB->>LlamaStackDB: select FAISS or PGVector BYOK template
LlamaStackDB->>LlamaStackDB: concatenate with LCS_BASE_TEMPLATE
LlamaStackDB->>Disk: write lightspeed-stack.yaml
Related PRs: None found. Suggested labels: enhancement, documentation Suggested reviewers: None identified. Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
src/lightspeed_rag_content/document_processor.py (2)
410-477: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueDuplicate
rag:block across FAISS/PGVector BYOK templates.
LCS_FAISS_BYOK_TEMPLATEandLCS_PGVECTOR_BYOK_TEMPLATEshare an identical trailingrag:section. Consider factoring this shared tail into a common template fragment to avoid future drift between the two variants.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/lightspeed_rag_content/document_processor.py` around lines 410 - 477, The FAISS and PGVector BYOK template constants in document_processor.py duplicate the same trailing rag section, so refactor the shared suffix into a single reusable fragment and have LCS_FAISS_BYOK_TEMPLATE and LCS_PGVECTOR_BYOK_TEMPLATE compose it, keeping the unique byok_rag portions separate to reduce drift and make updates easier.
867-869: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueParameter ordering differs from
write_yaml_config.
write_lcs_config(index, filename, vector_store_id, db_file)ordersvector_store_idbeforedb_file, while the siblingwrite_yaml_config(index_id, filename, db_file, files_metadata_db_file)puts db-related params first. Minor consistency nit, not blocking.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/lightspeed_rag_content/document_processor.py` around lines 867 - 869, The parameter order in write_lcs_config is inconsistent with write_yaml_config and should be aligned for readability and API consistency. Update write_lcs_config in document_processor.py so the db-related argument comes before the vector store identifier, matching the ordering style used by write_yaml_config and any internal call sites that may rely on this convention.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@README.md`:
- Around line 435-445: The README example currently reads like a complete
lightspeed-stack.yaml, but it is only the BYOK excerpt. Update the wording
around the byok_rag YAML snippet to explicitly say it is a partial example or
excerpt and that the generator also writes other required top-level sections, so
readers do not copy it as a full config.
In `@src/lightspeed_rag_content/document_processor.py`:
- Around line 308-313: The template’s provider list is missing the required
safety provider even though apis now includes safety. Update the provider
registration in document_processor so it also adds the matching providers.safety
entry with the inline::llama-guard provider, alongside the existing agents,
files, inference, tool_runtime, vector_io, and safety API setup.
---
Nitpick comments:
In `@src/lightspeed_rag_content/document_processor.py`:
- Around line 410-477: The FAISS and PGVector BYOK template constants in
document_processor.py duplicate the same trailing rag section, so refactor the
shared suffix into a single reusable fragment and have LCS_FAISS_BYOK_TEMPLATE
and LCS_PGVECTOR_BYOK_TEMPLATE compose it, keeping the unique byok_rag portions
separate to reduce drift and make updates easier.
- Around line 867-869: The parameter order in write_lcs_config is inconsistent
with write_yaml_config and should be aligned for readability and API
consistency. Update write_lcs_config in document_processor.py so the db-related
argument comes before the vector store identifier, matching the ordering style
used by write_yaml_config and any internal call sites that may rely on this
convention.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: de5b712a-e269-4d02-970e-af6f7c6fa620
📒 Files selected for processing (3)
README.mdsrc/lightspeed_rag_content/document_processor.pytests/test_document_processor_llama_stack.py
Fixes pylint too-many-lines (C0302) by moving all llama-stack and LCS configuration templates to config_templates.py. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
@syedriko Question: should I update the e2e tests to use the generated |
|
/retest |
Absolutely! |
2 participants
Description
After building a vector database, rag-content now generates a full, runnable
lightspeed-stack.yamlalongside the existingllama-stack.yaml. The generated config includes all required LCS sections (service, llama_stack, authentication, conversation_cache, user_data_collection) plus thebyok_ragentry andragretrieval strategy for the generated vector store.Both FAISS and pgvector backends are supported. The llama-stack config template is also updated with
agentsandsafetyAPIs required by LCS.Changes:
write_lcs_config()method with base + FAISS/pgvector BYOK templatessave()to writelightspeed-stack.yamlin the output directoryagentsandsafetyAPIs/providersType of change
Tools used to create PR
Related Tickets & Documents
Checklist before requesting a review
Testing
uv run make test-unit— all 207 tests passlightspeed-stack.yaml+llama-stack.yaml, queried/v1/queryand received RAG-augmented response with chunks from the test documentSummary by CodeRabbit
New Features
Bug Fixes