Add databricks deployments client skeleton + example #10421
Conversation
Signed-off-by: harupy <17039389+harupy@users.noreply.github.com>
|
Documentation preview for 8ab1694 will be available here when this CircleCI job completes successfully. More info
|
| def create_endpoint(self, name, config=None): | ||
| raise NotImplementedError("TODO") | ||
|
|
||
| def update_endpoint(self, endpoint, config=None): | ||
| raise NotImplementedError("TODO") | ||
|
|
||
| def delete_endpoint(self, endpoint): | ||
| raise NotImplementedError("TODO") | ||
|
|
||
| def list_endpoints(self): | ||
| raise NotImplementedError("TODO") | ||
|
|
||
| def get_endpoint(self, endpoint): | ||
| raise NotImplementedError("TODO") |
There was a problem hiding this comment.
I'll implement these later in a follow-up PR.
| def update_deployment(self, name, model_uri=None, flavor=None, config=None, endpoint=None): | ||
| raise NotImplementedError | ||
|
|
||
| def delete_deployment(self, name, config=None, endpoint=None): |
There was a problem hiding this comment.
Curious what values would be in config or endpoint here? Is there an option to delete an endpoint referenced by name but not the entire named deployment?
There was a problem hiding this comment.
I don't think we need xxx_deployment methods. They are abstract methods and need to be overridden. Users won't touch them.
|
|
||
|
|
||
| class DatabricksDeploymentClient(BaseDeploymentClient): | ||
| def create_deployment(self, name, model_uri, flavor=None, config=None, endpoint=None): |
There was a problem hiding this comment.
Is the model_uri going to be required if we're creating a gateway route, or is gateway route creation purely going to be handled with create_endpoint() ?
There was a problem hiding this comment.
do we need the flavor designator here? If we're using model_uri, can it read the configured flavor information from the MLmodel file?
There was a problem hiding this comment.
is gateway route creation purely going to be handled with create_endpoint() ?
yes
| raise NotImplementedError("TODO") | ||
|
|
||
|
|
||
| def run_local(name, model_uri, flavor=None, config=None): |
There was a problem hiding this comment.
Build a local serving container and validate the capacity to return inference predictions? Is that what this is? (if so, this is awesome)
There was a problem hiding this comment.
I'm actually not sure what this is for. A deployment plugin must define target_help and run_local. We can update them if necessary.
There was a problem hiding this comment.
The target_help implementation as explained in the ABC is definitely out of scope for a Databricks plugin (not entirely sure what that would return even if there was an available endpoint to target?). The run_local might also be a "maybe nice to have in the far-off future", but definitely something that would be rather challenging to simulate model serving behavior from within OSS.
馃洜 DevTools 馃洜
Install mlflow from this PR
Checkout with GitHub CLI
Related Issues/PRs
#xxxWhat changes are proposed in this pull request?
Title
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/artifacts: Artifact stores and artifact loggingarea/build: Build and test infrastructure for MLflowarea/docs: MLflow documentation pagesarea/examples: Example codearea/gateway: AI Gateway service, Gateway client APIs, third-party Gateway integrationsarea/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registryarea/models: MLmodel format, model serialization/deserialization, flavorsarea/recipes: Recipes, Recipe APIs, Recipe configs, Recipe Templatesarea/projects: MLproject format, project running backendsarea/scoring: MLflow Model server, model deployment tools, Spark UDFsarea/server-infra: MLflow Tracking server backendarea/tracking: Tracking Service, tracking client APIs, autologgingInterface
area/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev serverarea/docker: Docker use across MLflow's components, such as MLflow Projects and MLflow Modelsarea/sqlalchemy: Use of SQLAlchemy in the Tracking Service or Model Registryarea/windows: Windows supportLanguage
language/r: R APIs and clientslanguage/java: Java APIs and clientslanguage/new: Proposals for new client languagesIntegrations
integrations/azure: Azure and Azure ML integrationsintegrations/sagemaker: SageMaker integrationsintegrations/databricks: Databricks integrationsHow 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 notes