-
Notifications
You must be signed in to change notification settings - Fork 99
LCORE-2345: docs migration to unified mode as primary #2450
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -79,6 +79,29 @@ All those deployments methods will be covered later. | |
|
|
||
|
|
||
|
|
||
| ## Configuration modes | ||
|
|
||
| *LCS* reads one operator-facing file: `lightspeed-stack.yaml`. There are two | ||
| ways it can drive the underlying Llama Stack: | ||
|
|
||
| 1. **Unified mode (recommended).** The single `lightspeed-stack.yaml` is the | ||
| only configuration file you maintain. LCORE *synthesizes* the Llama Stack | ||
| `run.yaml` from it at startup — from a built-in default baseline, an | ||
| optional [profile](#profiles) you author, the high-level | ||
| `inference.providers` section, and a raw `native_override` escape hatch. | ||
|
Comment on lines
+87
to
+91
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win Clarify that unified mode can use a user-maintained profile. The guide describes
📍 Affects 1 file
🤖 Prompt for AI Agents |
||
| All examples in this guide show unified mode first. | ||
| 2. **Legacy two-file mode (deprecated).** `llama_stack.library_client_config_path` | ||
| points at an external, hand-maintained `run.yaml`. This path is deprecated: | ||
| since release 0.6 it logs a startup warning, and it is **removed in | ||
| release 0.7**. See | ||
| [Migrating from the legacy two-file configuration](#migrating-from-the-legacy-two-file-configuration). | ||
|
|
||
| The two modes are mutually exclusive in one file — configuration loading | ||
| fails if a unified synthesis input and `library_client_config_path` are both | ||
| present. | ||
|
|
||
|
|
||
|
|
||
| ## Integration with Llama Stack framework | ||
|
|
||
| The Llama Stack framework can be run as a standalone server and accessed via its the REST API. However, instead of direct communication via the REST API (and JSON format), there is an even better alternative. It is based on the so-called Llama Stack Client. It is a library available for Python, Swift, Node.js or Kotlin, which "wraps" the REST API stack in a suitable way, which is easier for many applications. | ||
|
|
@@ -92,7 +115,11 @@ When this mode is selected, Llama Stack is used as a regular Python library. Thi | |
|  | ||
|
|
||
| > [!NOTE] | ||
| > Even when Llama Stack is used as a library, it still requires the configuration file `run.yaml` to be presented. This configuration file is loaded during initialization phase. | ||
| > Even when Llama Stack is used as a library, it still requires a `run.yaml` | ||
| > configuration during the initialization phase. In unified mode (the | ||
| > recommended default) LCORE synthesizes that file for you from | ||
| > `lightspeed-stack.yaml`; only the deprecated legacy mode requires you to | ||
| > maintain `run.yaml` by hand. | ||
|
|
||
|
|
||
|
|
||
|
|
@@ -160,6 +187,78 @@ When this mode is selected, Llama Stack is started as a separate REST API servic | |
|
|
||
|
|
||
|
|
||
| ## Migrating from the legacy two-file configuration | ||
|
|
||
| Three migration paths, per deployment: | ||
|
|
||
| | Path | Effort | Result | | ||
| |---|---|---| | ||
| | Do nothing | none | Legacy keeps working until removal in 0.7 (with a startup deprecation warning) | | ||
| | Lift-and-shift | seconds — `--migrate-config` | Single file, byte-equivalent Llama Stack behavior | | ||
| | Re-express | hours+ | Single file; high-level sections and/or a profile replace the lifted `run.yaml` | | ||
|
|
||
| ### Step-by-step: lift-and-shift with `--migrate-config` | ||
|
|
||
| Given a legacy pair — a hand-maintained `run.yaml` plus a | ||
| `lightspeed-stack.yaml` that points at it: | ||
|
|
||
| ```yaml | ||
| # lightspeed-stack.yaml (legacy, deprecated) | ||
| name: LCS | ||
| llama_stack: | ||
| use_as_library_client: true | ||
| library_client_config_path: ./run.yaml | ||
| # ... rest ... | ||
| ``` | ||
|
|
||
| 1. Run the migration tool: | ||
|
|
||
| ```bash | ||
| lightspeed-stack --migrate-config \ | ||
| --run-yaml run.yaml \ | ||
| -c lightspeed-stack.yaml \ | ||
| --migrate-output lightspeed-stack-unified.yaml | ||
| ``` | ||
|
|
||
| 2. Inspect the output. Everything from your `lightspeed-stack.yaml` is | ||
| preserved; only the `llama_stack` section changes — | ||
| `library_client_config_path` is removed and your entire `run.yaml` is | ||
| lifted into the unified config block: | ||
|
|
||
| ```yaml | ||
| # lightspeed-stack-unified.yaml | ||
| name: LCS | ||
| llama_stack: | ||
| use_as_library_client: true | ||
| config: | ||
| baseline: empty | ||
| native_override: | ||
| # ... your run.yaml content, verbatim ... | ||
| ``` | ||
|
|
||
| 3. Replace literal secrets. If your `run.yaml` contained secret values | ||
| directly, replace them with `${env.MY_VAR}` environment references — | ||
| the migrated file otherwise carries them onto disk verbatim (the | ||
| synthesized output is written owner-only, mode 0600, as a safety net). | ||
|
|
||
| 4. Swap the file in (`mv lightspeed-stack-unified.yaml | ||
| lightspeed-stack.yaml`), delete the now-unused external `run.yaml` | ||
| mount/copy, and restart. Llama Stack behavior is identical: synthesis | ||
| starts from an empty baseline and deep-merges only your lifted | ||
| `run.yaml`. | ||
|
|
||
| Later, at your own pace, you can slim the `native_override` down by moving | ||
| providers into the high-level `inference.providers` section or into a | ||
| [profile](#profiles) — that is the "re-express" path. | ||
|
|
||
| ### Deprecation schedule | ||
|
|
||
| Unified mode shipped in release 0.6 with legacy mode fully functional plus | ||
| a startup deprecation warning; the legacy two-file path is removed in | ||
| release 0.7. | ||
|
|
||
|
|
||
|
|
||
| ## Local deployment | ||
|
|
||
| In this chapter it will be shown how to run LCS locally. This mode is especially useful for developers, as it is possible to work with the latest versions of source codes, including locally made changes and improvements. And last but not least, it is possible to trace, monitor and debug the entire system from within integrated development environment etc. | ||
|
|
@@ -542,12 +641,17 @@ cp examples/run.yaml . | |
|
|
||
|
|
||
| #### LCS configuration to use Llama Stack in library mode | ||
| Copy the example LCS config file from examples/lightspeed-stack-library.yaml to the project directory: | ||
| Copy the example LCS config file from examples/lightspeed-stack-lls-library.yaml to the project directory: | ||
|
|
||
| ```bash | ||
| cp examples/lightspeed-stack-lls-library.yaml lightspeed-stack.yaml | ||
| ``` | ||
|
|
||
| The example is a unified-mode configuration: the `run.yaml` you created above | ||
| is consumed as the synthesis [profile](#profiles) via | ||
| `llama_stack.config.profile` — there is no deprecated | ||
| `library_client_config_path` in it. | ||
|
|
||
|
|
||
| #### Start LCS | ||
|
|
||
|
|
@@ -1074,7 +1178,9 @@ Create a file named `run.yaml`. Use the example configuration from [examples/run | |
|
|
||
| ### LCS configuration | ||
|
|
||
| Create file `lightspeed-stack.yaml` with the following content: | ||
| Create file `lightspeed-stack.yaml` with the following content (unified | ||
| mode — the `run.yaml` created above is consumed as the synthesis | ||
| [profile](#profiles)): | ||
|
|
||
| ```yaml | ||
| name: Lightspeed Core Service (LCS) | ||
|
|
@@ -1087,7 +1193,8 @@ service: | |
| access_log: true | ||
| llama_stack: | ||
| use_as_library_client: true | ||
| library_client_config_path: ./run.yaml | ||
| config: | ||
| profile: ./run.yaml | ||
| api_key: xyzzy | ||
| user_data_collection: | ||
| feedback_enabled: true | ||
|
|
@@ -1099,6 +1206,12 @@ authentication: | |
| module: "noop" | ||
| ``` | ||
|
|
||
| > [!WARNING] | ||
| > The legacy equivalent — `library_client_config_path: ./run.yaml` instead | ||
| > of the `config:` block — is deprecated and will be removed in release | ||
| > 0.7. See | ||
| > [Migrating from the legacy two-file configuration](#migrating-from-the-legacy-two-file-configuration). | ||
|
|
||
|
|
||
| ### Start *Lightspeed Core Service* from a container | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -841,8 +841,12 @@ class LlamaStackConfiguration(ConfigurationBase): | |
|
|
||
| library_client_config_path: Optional[str] = Field( | ||
| None, | ||
| title="Llama Stack configuration path", | ||
| description="Path to configuration file used when Llama Stack is run in library mode", | ||
| title="Llama Stack configuration path (legacy, deprecated)", | ||
| description="Path to configuration file used when Llama Stack is run " | ||
| "in library mode. DEPRECATED legacy two-file setup: logs a startup " | ||
| "warning since 0.6 and is removed in 0.7 — use unified mode instead " | ||
| "(the config block below, and/or the root-level inference.providers " | ||
| "section); migrate with lightspeed-stack --migrate-config.", | ||
|
Comment on lines
842
to
+849
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
# Expect the schema entry for library_client_config_path to contain deprecated: true.
jq -e '
..
| objects
| select(.properties? and .properties.library_client_config_path?)
| .properties.library_client_config_path.deprecated == true
' docs/devel_doc/openapi.json >/dev/nullRepository: lightspeed-core/lightspeed-stack Length of output: 170 🏁 Script executed: #!/bin/bash
set -euo pipefail
printf '%s\n' '--- field definition and nearby model ---'
sed -n '810,865p' src/models/config.py
printf '%s\n' '--- Pydantic version/context references ---'
rg -n --glob 'pyproject.toml' --glob 'requirements*.txt' --glob '*.lock' 'pydantic|fastapi' . | head -80
printf '%s\n' '--- schema occurrences ---'
rg -n -C 5 'library_client_config_path|deprecated' docs/devel_doc/openapi.json src/models/config.py | head -160
printf '%s\n' '--- schema files ---'
git ls-files | rg '(^|/)(openapi|schema).*\.json$|openapi\.json$' | head -80Repository: lightspeed-core/lightspeed-stack Length of output: 27372 Expose deprecation in the generated schema. The checked-in OpenAPI schema omits 🤖 Prompt for AI AgentsSource: MCP tools |
||
| ) | ||
|
|
||
| timeout: PositiveInt = Field( | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
Use one consistent unified-configuration contract.
The documentation must distinguish the
lightspeed-stack.yamlschema from profile and Llama Stackrun.yamlcontent.docs/devel_doc/providers.md#L4-L4: documentconfig.profile,config.native_override, and root-levelinference.providersexplicitly.docs/user_doc/rag_guide.md#L230-L230: identify whether the vLLM block belongs inconfig.profileor in unified root configuration.docs/user_doc/rag_guide.md#L253-L253: apply the same destination and nesting clarification to the OpenAI example.📍 Affects 2 files
docs/devel_doc/providers.md#L4-L4(this comment)docs/user_doc/rag_guide.md#L230-L230docs/user_doc/rag_guide.md#L253-L253🤖 Prompt for AI Agents