Update agent examples and quickstart to support Lakebase Autoscaling#151
Update agent examples and quickstart to support Lakebase Autoscaling#151jennsun wants to merge 8 commits intodatabricks:mainfrom
Conversation
- Add autoscaling (project/branch) as an alternative to provisioned Lakebase instances across all 3 memory templates - Detect app environment via DATABRICKS_APP_NAME and use PGENDPOINT (auto-injected by platform) for autoscaling in deployed apps - Update quickstart to support creating new Lakebase instances or connecting to existing provisioned/autoscaling instances - Use autoscaling_endpoint parameter (renamed in databricks-ai-bridge) - Add databricks-ai-bridge git dependency for autoscaling support - Update tests to remove update_databricks_yml_lakebase references Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
248b026 to
e39267c
Compare
.scripts/source/test_quickstart.py
Outdated
| endpoint_type: ENDPOINT_TYPE_READ_WRITE | ||
| autoscaling_limit_min_cu: 0.5 | ||
| autoscaling_limit_max_cu: 4 | ||
|
|
There was a problem hiding this comment.
note: DABs -> app resources for autoscaling is not ready yet so testing gets:
Error: Exit code 1
Warning: unknown field: postgres
at resources.apps.agent_langgraph_long_term_memory.resources[1]
in databricks.yml:42:11
Uploading bundle files to /Workspace/Users/jenny.sun@databricks.com/.bundle/agent_langgraph_long_term_memory/dev/files...
Error: exit status 1
Error: Invalid Attribute Combination
in the meantime we will test by adding it as a resource to apps manually and deploying dab without this resource
| # Note: Using git reference until official release | ||
| "databricks-langchain[memory] @ git+https://github.com/databricks/databricks-ai-bridge@lakebase-autoscaling-support#subdirectory=integrations/langchain", | ||
| "databricks-ai-bridge @ git+https://github.com/databricks/databricks-ai-bridge@lakebase-autoscaling-support", | ||
| "databricks-agents>=1.9.3", |
There was a problem hiding this comment.
will remove after release
dhruv0811
left a comment
There was a problem hiding this comment.
Looks good overall!! Left some comments for local testing cleanup and some clarifications on lakebase options.
.gitignore
Outdated
| !.claude/AGENTS.md | ||
| !.claude/CLAUDE.md No newline at end of file | ||
| !.claude/CLAUDE.md | ||
| /agent-langgraph-long-term-memory/e2e-chatbot-app-next |
There was a problem hiding this comment.
I dont think the chatbot UI template should be here? users might want to edit it themselves in the future.
There was a problem hiding this comment.
accidentally added this during my own testing, let me revert
| database: | ||
| instance_name: '<your-lakebase-instance-name>' | ||
| database_name: 'databricks_postgres' | ||
| - name: 'postgres' |
There was a problem hiding this comment.
nit: couple comments around here saying this is for autoscaling, see below for provisioned?
| # TODO: Update with your Lakebase instance for session storage | ||
| # Option 1: Provisioned instance (set instance name) | ||
| # LAKEBASE_INSTANCE_NAME= | ||
| # Option 2: Autoscaling instance (set project and branch) |
There was a problem hiding this comment.
Did we not have a third option with just autoscaling_endpoint?
There was a problem hiding this comment.
the thinking here is that when users develop locally, they do so via passing in project/branch name. the autoscaling_endpoint is only used when we are in the app environment and we can directly read from PGENDPOINT (since it's not as user friendly to pass in) - hence adding this check: https://github.com/databricks/app-templates/pull/151/changes#diff-1e8ffff9ea9c91fc9dce7d8af129175d1fcfe357eabbcec14705feff13eeacacR53
| !.claude/skills/migrate-from-model-serving/ | ||
|
|
||
| # Exclude e2e chatbot app (separate project) | ||
| e2e-chatbot-app-next/ No newline at end of file |
There was a problem hiding this comment.
The user might want to modify the chatbot UI on their own in the future after cloning a template. We shouldn't be including this in the gitignore.
| # Define the app as a module level variable to enable multiple workers | ||
| app = agent_server.app # noqa: F841 | ||
| setup_mlflow_git_based_version_tracking() | ||
| try: |
There was a problem hiding this comment.
Nit: why are we catching a broad exception for this? In which cases does this mlflow setup not work easily?
| # Check for Lakebase access/connection errors | ||
| if any(keyword in error_msg for keyword in ["permission"]): | ||
| logger.error(f"Lakebase access error: {e}") | ||
| lakebase_desc = LAKEBASE_INSTANCE_NAME or LAKEBASE_AUTOSCALING_ENDPOINT or f"{LAKEBASE_AUTOSCALING_PROJECT}/{LAKEBASE_AUTOSCALING_BRANCH}" |
There was a problem hiding this comment.
Is it worth doing some validation like we did in the SDK to ensure that we only have one valid combination of variables set here? Say a user has project and branch set, but accidentally also set instance name, they should be notified rather than silently picking up instance name and short circuiting here.
There was a problem hiding this comment.
Same here, not sure if we want these changes to be persisted to app templates? They look like local testing changes.
updated quickstart experience to select instance:


examples work
