[Endpoints] [7/x] Add rest store implementation#19008
[Endpoints] [7/x] Add rest store implementation#19008BenWilson2 merged 1 commit intomlflow:masterfrom
Conversation
da8167e to
e6b9861
Compare
eee09fd to
0a0523d
Compare
0a0523d to
8738ac2
Compare
f57e5af to
4fc4111
Compare
d3c8fb5 to
e736d1c
Compare
|
Documentation preview for 03c364d is available at: More info
|
7e7a193 to
6915f33
Compare
da5f51d to
68f01c4
Compare
|
|
||
|
|
||
| class RestStore(AbstractStore): | ||
| class RestStore(RestGatewayStoreMixin, AbstractStore): |
There was a problem hiding this comment.
Since AbstractStore inherits GatewayStoreMixin, RestGatewayStoreMixin needs to be passed first, correct? Depending on the order of parent classes seems risky, can we add a comment for the future reminder?
| from mlflow.utils.proto_json_utils import message_to_json | ||
|
|
||
|
|
||
| class RestGatewayStoreMixin: |
There was a problem hiding this comment.
Should we implement get_resource_endpoint_configs as well?
There was a problem hiding this comment.
Ah, we can't create any REST endpoints for that API (that would allow any user to get any decrypted key). In order to make sure that we don't ever accidentally add that as a feature, I removed this API from the standard store mixins and put it in store/tracking/gateway with some NB notes and guidance about how dangerous use of this API outside of the tracking server is.
There was a problem hiding this comment.
Understood, where did you make the change to remove get_resource_endpoint_configs from the general store mixin?
There was a problem hiding this comment.
Ah it was for the feedback in sql-store that @B-Step62 mentioned... it's the right call to separate this out for future dev security.
| # Endpoint Bindings APIs | ||
| CreateGatewayEndpointBinding: _create_endpoint_binding, | ||
| DeleteGatewayEndpointBinding: _delete_endpoint_binding, | ||
| ListGatewayEndpointBindings: _list_endpoint_bindings, |
There was a problem hiding this comment.
Shall we add proto for get_resource_endpoint_configs?
There was a problem hiding this comment.
^ same answer as preceding question
dc518e8 to
77da1a1
Compare
mlflow/entities/gateway_endpoint.py
Outdated
| proto.resource_type = ( | ||
| self.resource_type.value | ||
| if isinstance(self.resource_type, GatewayResourceType) | ||
| else self.resource_type |
There was a problem hiding this comment.
Do we need else branch? We only expect GatewayResourceType in this field.
mlflow/server/handlers.py
Outdated
| CreateGatewaySecret(), | ||
| schema={ | ||
| "secret_name": [_assert_required, _assert_string], | ||
| "secret_value": [_assert_required, _assert_string], |
There was a problem hiding this comment.
These assertion logic seems to print the value directly in the error message. Even if it does not, these are pretty generic utils so we can accidentally add display logic. Should we have a special validation logic to avoid the risk of such leakage?
Also worth checking the other general logic like message_to_json does not expose unencrypted values to the rest error or the server logs.
There was a problem hiding this comment.
Good catch - we need a separate validation handler that is only used for the APIs interfacing with plaintext API Keys to guard against any potential future log leakage. Updated
mlflow/server/handlers.py
Outdated
| UpdateGatewaySecret(), | ||
| schema={ | ||
| "secret_id": [_assert_required, _assert_string], | ||
| "secret_value": [_assert_required, _assert_string], |
There was a problem hiding this comment.
Is secret value required? Shall we allow users to update auth config only?
There was a problem hiding this comment.
Good idea - this definitely makes the 4 providers that have complex configs a bit more flexible. We can handle single-key missing value entries guarded in the UI (do not allow editing a key that only has API KEY to set an empty string).
| self, | ||
| endpoint_id: str, | ||
| model_definition_id: str, | ||
| weight: int = 1, |
There was a problem hiding this comment.
yep - missed updating that!
Signed-off-by: Ben Wilson <benjamin.wilson@databricks.com>
77da1a1 to
03c364d
Compare
🥞 Stacked PR
Use this link to review incremental changes.
Related Issues/PRs
#xxxWhat changes are proposed in this pull request?
Adds the rest store implementation and e2e backend tests
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.