[MLflow Demo] Base implementation for demo framework#19994
[MLflow Demo] Base implementation for demo framework#19994BenWilson2 merged 1 commit intomlflow:masterfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR introduces a base implementation for a demo framework that allows generating demo data for MLflow features. The framework provides a registry pattern for demo generators with versioning support to automatically regenerate demo data when the schema changes.
Changes:
- Adds base classes (
BaseDemoGenerator,DemoResult) for implementing demo data generators - Implements a registry pattern (
DemoRegistry) for managing multiple demo generators - Includes version tracking to handle demo data migration on updates
Reviewed changes
Copilot reviewed 8 out of 10 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| mlflow/demo/base.py | Core framework with abstract base class for generators, dataclass for results, and version management |
| mlflow/demo/registry.py | Registry implementation for discovering and managing demo generators |
| mlflow/demo/init.py | Public API with generate_all_demos() function |
| mlflow/demo/README.md | Documentation on design principles, creating generators, and versioning |
| mlflow/demo/generators/init.py | Empty module for future generator implementations |
| tests/demo/conftest.py | Test fixtures with stub generator implementations |
| tests/demo/test_base.py | Tests for base class validation, versioning, and data existence checks |
| tests/demo/test_registry.py | Tests for registry operations (register, get, list, contains) |
| tests/demo/test_generate.py | Tests for the main generation flow with version management |
| tests/demo/init.py | Empty test module initialization |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Documentation preview for 6ced72e is available at: More info
|
72f8820 to
9d64af4
Compare
mlflow/demo/README.md
Outdated
|
|
||
| ## Design Principles | ||
|
|
||
| 1. **Auto-generated on startup** - Demo data is created when `mlflow server` starts, requiring no user action. |
There was a problem hiding this comment.
I think users don't want this in prod. We could provide an option to disable demo data generation but that's inconvenient since they have to set it.
There was a problem hiding this comment.
+1, I thought we would introduce a UI or cli hook like mlflow demo generate instead of generating a demo data by default
There was a problem hiding this comment.
The worst scenario is the data generation step has a bug and block users.
There was a problem hiding this comment.
Yep, agreed. I'm going to update that internal README with the 2 entry point paths (cli / UI-based ajax call) as well as providing information about why, for the existing users who generate demo data in their tracking server and then upgrade to a newer version of the tracking server why we'll want to have versioning available to prevent potentially broken demo experiences.
mlflow/demo/base.py
Outdated
| navigation_url: URL path to navigate to view the demo data in the UI. | ||
| """ | ||
|
|
||
| feature: str |
There was a problem hiding this comment.
Can we define an enum for the feature field?
There was a problem hiding this comment.
good call on keeping this cleaner
mlflow/demo/base.py
Outdated
| """ | ||
|
|
||
| feature: str | ||
| entities_created: list[str] |
There was a problem hiding this comment.
Do we want to return an identifier instead of the actual entity? Then can we rename this field?
There was a problem hiding this comment.
yep! Changed to entity_ids to be more accurate.
| from mlflow.demo.base import DEMO_EXPERIMENT_NAME, DEMO_PROMPT_PREFIX | ||
| ``` | ||
|
|
||
| ## Versioning |
There was a problem hiding this comment.
Do we really need this? Can you explain a scenario where this is useful?
There was a problem hiding this comment.
Added some explanation for why we will likely really want this functionality within the README.
9d64af4 to
5929f11
Compare
5929f11 to
f7b4b07
Compare
mlflow/demo/README.md
Outdated
| ### When to Bump Version | ||
|
|
||
| Bump the version when making changes to demo data that require regeneration: | ||
|
|
||
| - Changing the structure of generated traces/spans | ||
| - Adding new required fields to assessments or evaluations | ||
| - Modifying prompt templates | ||
| - Any change that makes old demo data incompatible with the current UI |
There was a problem hiding this comment.
Suppose we have a typo in the demo data. Do we need to bump the version to fix the typo?
There was a problem hiding this comment.
It appears we always to need to bump the version to refresh the demo data in a user machine
There was a problem hiding this comment.
I think we should to ensure that if the demo data is already on a running tracking server, we can hot reload only for version mismatches. The reason I think this is important is because of the latency involved with generating trace linkages (writing association table mappings for trace linking takes several seconds) and forcing reload of the contents violates the goal of idempotency in the data generation.
Hopefully we won't have typos though, since lint rules are pretty solid.
| def _data_exists(self) -> bool: | ||
| """Check if demo data exists (regardless of version).""" | ||
|
|
||
| def delete_demo(self) -> None: |
There was a problem hiding this comment.
should we @abstractmethod here too?
There was a problem hiding this comment.
I didn't want to force demos that don't need direct cleanup of data (transitive demos that might do something with data that another demo generates to showcase functionality) to have to create a concrete implementation that is a no-op. It's purely to reduce boilerplate.
mlflow/demo/README.md
Outdated
| - Modifying prompt templates | ||
| - Any change that makes old demo data incompatible with the current UI | ||
|
|
||
| ## Creating a New Generator |
There was a problem hiding this comment.
Do we expect users to implement a custom demo generator?
There was a problem hiding this comment.
Not at all. The README is for maintainers / contributors for providing guidance on how to add new demos. Added statements to this doc to make that clear.
mlflow/demo/README.md
Outdated
| - Creates a temporary, self-contained environment (SQLite in temp directory) | ||
| - Generates demo data automatically on startup | ||
| - Opens browser directly to the MLflow Demo experiment | ||
| - Auto-cleanup on exit |
There was a problem hiding this comment.
is there a reason we don't cache the generated data? This would be painful if the demo data generation is slow (e.g., 10 seconds).
There was a problem hiding this comment.
The full demo data takes less than 1s to generate. It is faster than most loading spinners for other pages that have even modest amounts of data.
mlflow/demo/README.md
Outdated
| ### 2. Launch Demo Button (Home Page) | ||
|
|
||
| For users who start `mlflow server` normally: |
There was a problem hiding this comment.
For testing out the functionality in corporate environments where the server and associated commands are inaccessible to users, having the ability to generate this data silently from within the UI is critical.
| from dataclasses import dataclass | ||
| from enum import Enum | ||
|
|
||
| DEMO_EXPERIMENT_NAME = "MLflow Demo" |
There was a problem hiding this comment.
Is this experiment deletable? What if a user accidentally removes it and wants to restore, or a user deletes it after trying the demo, then another user attempts to do the demo?
There was a problem hiding this comment.
Yes, updated the README with all pertinent details
f7b4b07 to
c27098c
Compare
1a722f7 to
ba7f215
Compare
mlflow/demo/README.md
Outdated
| ### Test Structure | ||
|
|
||
| ``` | ||
| tests/demo/ | ||
| ├── conftest.py # Fixtures (tracking_uri for isolated environments) | ||
| ├── test_base.py # BaseDemoGenerator tests | ||
| ├── test_registry.py # DemoRegistry tests |
There was a problem hiding this comment.
Let's remove this. Agents can figure it out without this.
There was a problem hiding this comment.
I think this README.md is too detailed. That makes it easy for it to become outdated and hard to keep in sync with the codebase. Let's keep only the essentials.
Signed-off-by: Ben Wilson <benjamin.wilson@databricks.com>
ba7f215 to
6ced72e
Compare
🥞 Stacked PR
Use this link to review incremental changes.
Related Issues/PRs
#xxxWhat changes are proposed in this pull request?
Adds the scaffolding framework for MLflow in-product demos.
Going with a template-based ABC approach here to make additions, modifications, and updates / fixes a bit more straightforward for maintenance and extension of these demos.
CI configuration with the first demo data generation (for traces) is added in #19995
How is this PR tested?
Does this PR require documentation update?
Release Notes
Is this a user-facing change?
What component(s), interfaces, languages, and integrations does this PR affect?
Components
area/tracking: Tracking Service, tracking client APIs, autologgingarea/models: MLmodel format, model serialization/deserialization, flavorsarea/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registryarea/scoring: MLflow Model server, model deployment tools, Spark UDFsarea/evaluation: MLflow model evaluation features, evaluation metrics, and evaluation workflowsarea/gateway: MLflow AI Gateway client APIs, server, and third-party integrationsarea/prompts: MLflow prompt engineering features, prompt templates, and prompt managementarea/tracing: MLflow Tracing features, tracing APIs, and LLM tracing functionalityarea/projects: MLproject format, project running backendsarea/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev serverarea/build: Build and test infrastructure for MLflowarea/docs: MLflow documentation pagesHow should the PR be classified in the release notes? Choose one:
rn/none- No description will be included. The PR will be mentioned only by the PR number in the "Small Bugfixes and Documentation Updates" sectionrn/breaking-change- The PR will be mentioned in the "Breaking Changes" sectionrn/feature- A new user-facing feature worth mentioning in the release notesrn/bug-fix- A user-facing bug fix worth mentioning in the release notesrn/documentation- A user-facing documentation change worth mentioning in the release notesShould this PR be included in the next patch release?
Yesshould be selected for bug fixes, documentation updates, and other small changes.Noshould be selected for new features and larger changes. If you're unsure about the release classification of this PR, leave this unchecked to let the maintainers decide.What is a minor/patch release?
Bug fixes, doc updates and new features usually go into minor releases.
Bug fixes and doc updates usually go into patch releases.