Example configurations with quota limiter setup #709
Conversation
WalkthroughTwo new example YAML configuration files are introduced for Lightspeed Core Service quota limiting setups: one using PostgreSQL backend and another using SQLite. Each defines server settings, llama_stack client configuration, authentication, conversation caching, and quota handlers with user and cluster limiters. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 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: 5
🧹 Nitpick comments (4)
examples/quota-limiter-configuration-sqlite.yaml (2)
36-46: Add clarification for commented-out byok_rag section.The BYOK RAG configuration block is disabled without explanation. Add a brief comment explaining when this should be enabled or remove it if not relevant to this example.
-#byok_rag: -# - rag_id: ocp_docs +# Uncomment below to enable Bring-Your-Own-Knowledge RAG if needed: +# byok_rag: +# - rag_id: ocp_docs
52-61: Clarify quota limiter period semantics in comments.The limiter names suggest "monthly" cadence, but the periods are "2 hours" and "1 day". Add inline comments to clarify whether these reset at the configured period (not monthly) or if the names are misleading.
limiters: - name: user_monthly_limits type: user_limiter + # Quota resets every 2 hours (not monthly, despite the name) initial_quota: 10 quota_increase: 10 period: "2 hours" - name: cluster_monthly_limits type: cluster_limiter + # Quota resets every 1 day (not monthly, despite the name) initial_quota: 100 quota_increase: 10 period: "1 day"Consider renaming to clarify the actual reset period (e.g.,
user_periodic_limits,cluster_daily_limits).examples/quota-limiter-configuration-pg.yaml (2)
33-34: Enable SSL for database connections in production example.Both database connection blocks (conversation_cache and quota_handlers) have SSL and GSS encryption disabled. For a production-oriented example, these should be enabled or at minimum documented with security implications.
- ssl_mode: disable - gss_encmode: disable + ssl_mode: require # Use 'disable' only for local development/testing + gss_encmode: disableAlternatively, add a comment explaining the security tradeoff:
# ⚠️ Only disable SSL for local development; enable for production - ssl_mode: disable - gss_encmode: disable + ssl_mode: require + gss_encmode: requireAlso applies to: 43-44
46-55: Align limiter documentation with sqlite variant; clarify period semantics.Like the sqlite configuration, the limiter names suggest "monthly" cadence but reset periods are "2 hours" and "1 day". Add clarifying comments and consider renaming for consistency.
limiters: - name: user_monthly_limits type: user_limiter + # Quota resets every 2 hours (not monthly, despite the name) initial_quota: 10 quota_increase: 10 period: "2 hours" - name: cluster_monthly_limits type: cluster_limiter + # Quota resets every 1 day (not monthly, despite the name) initial_quota: 100 quota_increase: 10 period: "1 day"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
examples/quota-limiter-configuration-pg.yaml(1 hunks)examples/quota-limiter-configuration-sqlite.yaml(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build-pr
- GitHub Check: e2e_tests (azure)
- GitHub Check: e2e_tests (ci)
| host: 0.0.0.0 | ||
| port: 8080 | ||
| auth_enabled: false |
There was a problem hiding this comment.
Add security warning for development-only configuration.
This configuration is unsafe for production: all interfaces exposed (0.0.0.0), authentication disabled, and SSL/encryption disabled on database connections (lines 33, 43).
Add a prominent warning at the file header:
+# ⚠️ WARNING: This is a development/example configuration only.
+# Do NOT use in production. Ensure:
+# - auth_enabled is set to true
+# - host is restricted to 127.0.0.1 or a specific network interface
+# - All credentials are updated from placeholder values
+# - Enable ssl_mode and gss_encmode for database connections
+#
name: Lightspeed Core Service (LCS)Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In examples/quota-limiter-configuration-pg.yaml around lines 3 to 5, add a
prominent top-of-file security warning comment stating this configuration is for
development only (exposes all interfaces 0.0.0.0, has auth disabled, and DB
SSL/encryption disabled — see DB settings at lines 33 and 43), and include
recommended actions: limit host to localhost, enable authentication, enable
SSL/encryption for DB connections, and avoid committing this file or use
environment-specific overrides for production.
| # use_as_library_client: true | ||
| # library_client_config_path: <path-to-llama-stack-run.yaml-file> | ||
| url: http://localhost:8321 | ||
| api_key: xyzzy |
There was a problem hiding this comment.
Replace hardcoded secrets with environment variable references.
Like the SQLite variant, this configuration includes plaintext credentials in multiple locations: the API key (line 17), conversation cache credentials (lines 30-32), and quota handler credentials (lines 41-42). These should be externalized.
Apply environment variable substitution pattern consistently:
url: http://localhost:8321
- api_key: xyzzy
+ api_key: ${LLAMA_STACK_API_KEY} # Set via environment variable postgres:
host: "127.0.0.1"
port: 5432
db: test
- user: tester
- password: 123qwe
+ user: ${DB_USER} # Change for production
+ password: ${DB_PASSWORD} # Change for production
ssl_mode: disable
gss_encmode: disableRepeat the same pattern for the quota_handlers postgres section below.
Also applies to: 30-32, 41-42
🤖 Prompt for AI Agents
In examples/quota-limiter-configuration-pg.yaml around lines 17, 30-32 and
41-42, replace the hardcoded secrets (api_key and all Postgres credentials in
the conversation cache and quota_handlers sections) with environment-variable
references following the same pattern used in the SQLite variant; create clear
env var names (e.g., QUOTA_API_KEY,
CONVERSATION_DB_HOST/PORT/USER/PASSWORD/NAME,
QUOTA_HANDLER_DB_USER/PASSWORD/HOST/PORT/NAME) and update each credential field
to read from those env vars consistently so no plaintext secrets remain in the
file.
| host: 0.0.0.0 | ||
| port: 8080 | ||
| auth_enabled: false |
There was a problem hiding this comment.
Add security warning for development-only configuration.
The service is configured to bind to all interfaces (0.0.0.0) with authentication disabled (auth_enabled: false). This is unsafe for any networked or production environment.
Add a prominent comment at the file header:
+# ⚠️ WARNING: This is a development/example configuration only.
+# Do NOT use in production. Ensure:
+# - auth_enabled is set to true
+# - host is restricted to 127.0.0.1 or a specific network interface
+# - All credentials are updated from placeholder values
+#
name: Lightspeed Core Service (LCS)Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In examples/quota-limiter-configuration-sqlite.yaml around lines 3 to 5, the
config binds to 0.0.0.0 and has auth_enabled: false which is unsafe; add a
prominent header comment above these lines warning this configuration is for
development only, explaining that binding to all interfaces and disabling auth
exposes the service to networks, and advise enabling authentication and
restricting bind address before using in any non-development or production
environment.
| # use_as_library_client: true | ||
| # library_client_config_path: <path-to-llama-stack-run.yaml-file> | ||
| url: http://localhost:8321 | ||
| api_key: xyzzy |
There was a problem hiding this comment.
Replace hardcoded secrets with environment variable references or clear placeholders.
Example configurations should not include actual (or easily guessable) credentials. Users who copy this file may inadvertently deploy with insecure defaults. Use environment variable substitution or add prominent comments indicating which values must be changed.
Consider updating to:
url: http://localhost:8321
- api_key: xyzzy
+ api_key: ${LLAMA_STACK_API_KEY} # Set via environment variableAnd for database credentials:
postgres:
host: 127.0.0.1
db: test
- user: tester
- password: 123qwe
+ user: ${DB_USER} # Change for production
+ password: ${DB_PASSWORD} # Change for productionAlso add a comment at the top of the file warning about these placeholders.
Also applies to: 30-32
🤖 Prompt for AI Agents
In examples/quota-limiter-configuration-sqlite.yaml around line 17 (and also
lines 30-32), the file contains hardcoded secrets (e.g., api_key and database
credentials); replace these with environment variable references or obvious
placeholders (for example use ${API_KEY} or <YOUR_API_KEY>), update any DB
username/password/host entries to use env vars or placeholders, and add a
prominent comment at the top of the file warning that values are placeholders
and must be replaced or provided via environment variables before deployment.
| quota_handlers: | ||
| sqlite: | ||
| db_path: quota.sqlite |
There was a problem hiding this comment.
Use absolute path or document the working directory context for SQLite database.
The relative path quota.sqlite (line 50) may cause the database to be created in unpredictable locations depending on where the service is executed. For production deployments, this could lead to data loss or permission issues.
Apply this diff to clarify the path:
sqlite:
- db_path: quota.sqlite
+ db_path: /var/lib/lightspeed/quota.sqlite # Adjust path as needed for your environmentAlternatively, add a comment explaining that the path is relative to the service's working directory and should be updated to an absolute path in production.
🤖 Prompt for AI Agents
In examples/quota-limiter-configuration-sqlite.yaml around lines 48-50, the
sqlite db_path uses a relative path ("quota.sqlite") which can create the DB in
unpredictable locations; update db_path to an absolute filesystem path
appropriate for the deployment (e.g., /var/lib/your-service/quota.sqlite) or, if
leaving it relative, add a clear comment above db_path stating that the path is
relative to the service's working directory and must be changed to an absolute
path for production to avoid data loss and permission issues.
1 participant
Description
Example configurations with quota limiter setup
Type of change
Summary by CodeRabbit