feat: add model registry client by jonburdo · Pull Request #186 · kubeflow/sdk

jonburdo · 2025-12-02T01:12:01Z

Add an api for model registry under a new kubeflow.hub submodule.

This takes the form of a ModelRegistryClient class which provides a kubeflow-style api for model-registry.

🤖 Generated with Claude Code

What this PR does / why we need it:

Which issue(s) this PR fixes (optional, in Fixes #<issue number>, #<issue number>, ... format, will close the issue(s) when PR gets merged):

Fixes #59

Checklist:

Docs included if any changes are user facing

details

This provides a possible api following this discussion. Also see the linked issue and the following:

github-actions · 2025-12-02T01:12:10Z

🎉 Welcome to the Kubeflow SDK! 🎉

Thanks for opening your first PR! We're happy to have you as part of our community 🚀

Here's what happens next:

If you haven't already, please check out our Contributing Guide for repo-specific guidelines and the Kubeflow Contributor Guide for general community standards
Our team will review your PR soon! cc @kubeflow/kubeflow-sdk-team

Join the community:

Slack: Join our #kubeflow-ml-experience and #kubeflow-trainer Slack channels
Meetings: Attend the Kubeflow SDK and ML Experience bi-weekly meetings

Feel free to ask questions in the comments if you need any help or clarification!
Thanks again for contributing to Kubeflow! 🙏

coveralls · 2025-12-02T01:14:37Z

Pull Request Test Coverage Report for Build 21182264396

Details

172 of 205 (83.9%) changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.9%) to 67.52%

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
kubeflow/hub/api/model_registry_client.py	47	51	92.16%
kubeflow/hub/api/model_registry_client_test.py	123	152	80.92%

Totals
Change from base Build 21147474427:	0.9%
Covered Lines:	2769
Relevant Lines:	4101

💛 - Coveralls

README.md

kubeflow/hub/api/model_registry_client.py

kubeflow/hub/api/model_registry_client_test.py

kramaranya

Thank you for this amazing work, @jonburdo!
Overall looks good, I left my initial comments
/assign @kubeflow/kubeflow-sdk-team

kramaranya · 2025-12-03T13:57:59Z

.github/workflows/check-pr-title.yaml

            ci
            docs
            examples
+            hub


Sorry I'm still a bit confused with hub vs model registry, @johnugeorge would you mind elaborating on this, specifically what do we expose to Kubeflow SDK users?
Shall this be model-registry or mr instead, since we only include only ModelRegistryClient?

I'm thinking kubeflow.hub is the appropriate submodule given:

We plan to rename from "Kubeflow Model Registry" to "Kubeflow Hub" assuming KEP-907 goes through.

The scope of the project is already broader than just model registry and it is conceivable that we could offer other clients in the future.

To highlight the point, we already have a model catalog and some basic experiment tracking. Now we don't plan to have kubeflow sdk clients for these afaik, but we are positioned to be able to extend the project for other AI/ML asset types (mcp, prompt management). We also have some storage helpers and integrations as outlined here.

Note my assumption here is basically that we want to have roughly one submodule per kubeflow sub-project. We could decide not to do this and then have kubeflow.model_registry and add separate submodules for any new clients or functionality we add later.

I see, thanks @jonburdo!

kramaranya · 2025-12-03T14:10:34Z

pyproject.toml

+hub = [
+  "model-registry>=0.3.0",
+]


I think we should include model-registry by default. wdyt @kubeflow/kubeflow-sdk-team
The issue is that Model Registry and other components already have their own extras, for example https://github.com/kubeflow/model-registry/blob/main/clients/python/pyproject.toml#L33-L36. We can't do "extras of extras", so if we tried to consolidate them we'd lose that functionality.
I think we should include core Kubeflow components by default (including model-registry) and reserve extras for third-party integrations like OpenTelemetry, MLflow, Hugging Face, etc.

I think the takeaway in the Kubeflow SDK & ML Experience WG call was that we will keep model-registry optional for now. I'm thinking that means we leave this as is - lmk if not.

A few other things to note:

The subset of model registry functions we are exposing here does not rely on the model-registry extras if I'm not mistaken

This doesn't prevent users from doing pip install 'model-registry[hf,boto3,olot]' if needed

Other options could include having kubeflow[hub] for model-registry and kubeflow[hub-all] for model-registry[hf,boto3,olot] if we really needed it (but I don't think we do)

Yes, let's keep the hub extras for now as we discussed. Later we can figure out a way how to manage extras of extras.

kramaranya · 2025-12-03T14:18:42Z

pyproject.toml


 [dependency-groups]
 dev = [
+  "kubeflow[hub]",


Suggested change

"kubeflow[hub]",

"model-registry>=0.3.0",

I think we just want to include anything in the hub extra rather than re-listing the packages.

README.md

kubeflow/hub/api/model_registry_client.py

jonburdo

I've made some updates and simplifications since the first iteration:

simplify __init__ and register_model
remove from_registry classmethod - We can have something that does this in ModelRegistry instead of here I think
return ModelVersion instead of ModelVersion | None from get_model_version - same for other get_* functions. Error if missing

jonburdo · 2025-12-04T02:43:27Z

Makefile

 	@uv lock --check
 	@uv run ruff check --show-fixes --output-format=github .
 	@uv run ruff format --check kubeflow
+	@uv run mypy kubeflow/hub --exclude '_test\.py$$'


I've added mypy - for now just on kubeflow/hub. It would simplify linting if we used the typical pattern of a separate test dir in the root of the repo for tests instead of mixing in *_test.py files, but I stuck with the existing pattern for now.

Can we use ruff for linting ? Using unified tool will allow us to reduce number of dependencies users have to install.

We are using ruff for linting, but it doesn't include type-checking, which we really want, so we also need mypy (e.g. if we're passing an int to str arg ruff won't catch that). The same org behind ruff is working on a type checker, ty, but it's relatively new and would still be a separate tool: https://github.com/astral-sh/ty

@kramaranya @szaher @astefanutti What are your thoughts on this? Shall we adopt ty for type checking?
@HumairAK @mprahl @hbelmiro @nsingla Are you planning to use any typing tool for Pipelines library?

@jonburdo have you tried to compare ty and mypy? does it cover everything you're using mypy for?

@andreyvelich No concrete plans at the moment. For the components/pipelines themselves, KFP doesn't really enforce or leverage Python type hints.
Adding a type checker for our scripts/CLIs could still be valuable. Though I'm guessing that's not the part you're asking about.

Looking again at ty, I think it's a good option. It will be faster and align with our use of uv and ruff. Replacing mypy with ty

README.md

kubeflow/hub/api/model_registry_client.py

jonburdo · 2025-12-04T19:54:14Z

I've addressed initial feedback and believe this is ready for review by @kubeflow/kubeflow-sdk-team

kubeflow/hub/api/model_registry_client.py

andreyvelich

Thank you for this @jonburdo! Overall, lgtm, I left a few comments.
cc @kubeflow/kubeflow-sdk-team

andreyvelich · 2026-01-09T15:32:53Z

Makefile

 	@uv lock --check
 	@uv run ruff check --show-fixes --output-format=github .
 	@uv run ruff format --check kubeflow
+	@uv run mypy kubeflow/hub --exclude '_test\.py$$'


Can we use ruff for linting ? Using unified tool will allow us to reduce number of dependencies users have to install.

andreyvelich · 2026-01-09T15:33:33Z

README.md

+```
+
+```python
+from kubeflow.hub import ModelRegistryClient


Are we going to have 2 clients in Hub? ModelRegistry and Catalog.

We have been discussing in KF Hub biweekly meeting that any new user facing client will be developed in KF SDK.
👉 So when the user need comes for a user facing py client for the Catalog, we'd directly develop this in KF SDK.
Hope this is satisfactory answer for ML WG (this group) and from KSC pov.

Detail note: from a E2E testing point of view, we need python based code generated clients for all the endpoints, which is something that for example ML WG (this group) mentioned is not interested in exposing, etc. So infrastructure code we need for the purpose of E2E, fuzz, and coverage testing of the endpoints, we're continuing maintaining in the KF/model-registry repo. We're open to revisit this setup too.

Great, thank you for sharing recording @tarilabs!

we need python based code generated clients for all the endpoints, which is something that for example ML WG (this group) mentioned is not interested in exposing, etc.

Yeah, that make sense. I guess, the conclusion was that we expose minimal set of APIs via kubeflow.hub package, and gather initial users feedback.
If users need other APIs that we don't expose via kubeflow.hub, they can always use it via this parameter:

self._registry()

Or import the client directly import model_registry.
In the future, we can potentially add more APIs to the kubeflow.hub directly.

The only question that I have, do users need two separate clients for Catalog and Model Registry APIs inside the kubeflow.hub sub package ?
e.g.:

from kubeflow.hub import ModelRegistryClient from kubeflow.hub import CatalogClient or just from kubeflow.hub import HubClient

Great, thank you for sharing recording @tarilabs!

we need python based code generated clients for all the endpoints, which is something that for example ML WG (this group) mentioned is not interested in exposing, etc.

Yeah, that make sense. I guess, the conclusion was that we expose minimal set of APIs via kubeflow.hub package, and gather initial users feedback. If users need other APIs that we don't expose via kubeflow.hub, they can always use it via this parameter:

self._registry()

Or import the client directly import model_registry. In the future, we can potentially add more APIs to the kubeflow.hub directly.

Great, sounds we are all aligned, personally glad and great to hear 👍

As for the latter question, my current assessment is:

from kubeflow.hub import ModelRegistryClient from kubeflow.hub import CatalogClient

as they're different patterns, and in turn different use-cases.
However as we'll define it in more concrete terms, we can refine the case more specifically then.
Hope this is understandable and fair.

Sure, that sounds great, thank you!

andreyvelich · 2026-01-09T15:35:20Z

pyproject.toml

+hub = [
+  "model-registry>=0.3.0",
+]


Yes, let's keep the hub extras for now as we discussed. Later we can figure out a way how to manage extras of extras.

andreyvelich · 2026-01-09T15:39:20Z

kubeflow/hub/api/model_registry_client_test.py

+        """Skip these tests if model-registry not installed."""
+        pytest.importorskip("model_registry")
+
+    def test_init_raises_helpful_error_when_not_installed(self, monkeypatch):


Please can you refactor these tests to align with this:

sdk/kubeflow/trainer/backends/kubernetes/backend_test.py

Line 635 in 854e6ba

def test_get_runtime(kubernetes_backend, test_case):

E.g. every test should align with the function name: test_register_model(test_case) and we create test cases via :

@pytest.mark.parametrize( "test_case", [ TestCase() ]

That will allow contributors to easily understand code and help with changes for Hub SDKs.

Sure, I've made this change. This does we are importing TestCase from kubeflow.trainer. I also have mixed feelings about this, but if it's something we want to standardize in the sdk, then I guess it works.

Thank you! Yes, eventually, we should have common types/helper function that we can re-use across packages.
This is yet another benefit to use common SDK to reduce code duplication and standardize on the code practices.

andreyvelich · 2026-01-09T15:40:36Z

kubeflow/hub/api/model_registry_client.py

+from collections.abc import Iterator, Mapping
+from typing import TYPE_CHECKING
+
+if TYPE_CHECKING:


Why do we need type checking here?

We want type annotations on the functions for better type-safety. LSPs will use them too (docs/checks in code editors). The if TYPE_CHECKING allows us to import things we may not have a runtime. mypy and LSPs will use the imports but if model-registry is missing we don't get an import error at this point.

Since hub is an optional dependency, we check for model-registry upon usage of the client ModelRegistryClient() rather than upon import as discussed:
#186 (comment)

Otherwise in a new env, this would error:

pip install kubeflow python -c 'import kubeflow.hub'

andreyvelich · 2026-01-09T15:43:39Z

kubeflow/hub/api/model_registry_client.py

+                 - http:// defaults to 8080
+                 - no scheme defaults to 443
+            author: Name of the author.
+            is_secure: Whether to use a secure connection. If not provided, inferred from base_url:


Same question, why not check it from the URL directly ?

#186 (comment)

is_secure is needed when you want to skip TLS verification, ie you have self-signed certs in a local development environment

We will default to is_secure=True for https and is_secure=False for http, but I believe we need to allow users to disable it too (is_secure=False with https) for development (shouldn't be done in production).

If it is only for development why not use http? Did you have use-cases when users want to verify https locally without secure connection?

Discussed in community call today. @tarilabs noted that this is important for certain use-cases. Users may use this library for development and have a need to use unsigned certificates.

Fwiw, we do leave this out of our primary quick-start examples in the README

andreyvelich · 2026-01-09T15:44:49Z

kubeflow/hub/api/model_registry_client.py

+        self._registry = ModelRegistry(
+            server_address=base_url,
+            port=port,
+            author=author,  # type: ignore[arg-type]


Since author is part of register_model API, does client still require it:

sdk/kubeflow/hub/api/model_registry_client.py

Line 88 in 854e6ba

author: str | None = None,

?

This provides a default value so it doesn't have to be passed to register_model every time it's called.

andreyvelich · 2026-01-09T15:46:23Z

kubeflow/hub/api/model_registry_client.py

+            name: Name of the model.
+            uri: URI of the model.
+
+        Keyword Args:


@kramaranya Do you know if we can auto-generate Kubeflow SDK docs from such format of docstring: Keyword Args?

Yes, I think it's configurable. I'll soon open a PR for the website and will verify it

andreyvelich · 2026-01-09T15:47:35Z

kubeflow/hub/api/model_registry_client.py

+        name: str,
+        uri: str,
+        *,
+        version: str,


Since version is mandatory parameter why you put it after "*" as keyword args?

It matches what we have in ModelRegistry and provides a little more flexibility if we want to re-order args after name, uri. I do wonder if we want to make version optional in the future and support an autogenerated version string if not provided.

I think, this is good idea. I would suggest to make it Optional.

Discussed in the community meeting. I believe we agreed to leave it as is for now. Apparently it becomes complicated if we try to provide a default as users won't always agree on if it should be uuid or incrementing v1, v2, ...

andreyvelich · 2026-01-09T15:48:51Z

kubeflow/hub/api/model_registry_client.py

+            TypeError: If model is not a RegisteredModel instance.
+            model_registry.exceptions.StoreError: If model does not have an ID.
+        """
+        from model_registry.types import RegisteredModel


Can we move all imports to the top of this file?

This would cause an immediate error upon import for import kubeflow.hub if the user has done:

pip install kubeflow

but not

pip install 'kubeflow[hub]'

We could opt for that. Or we could do a lazy import. I would suggest leaving it as-is though.

But since we put it under TYPE_CHECKING that should be fine, isn't?

sdk/kubeflow/hub/api/model_registry_client.py

Line 6 in 7f41fa7

if TYPE_CHECKING:

In this function if not isinstance(model, RegisteredModel): needs to have RegisteredModel at runtime.

For example, if you use from __future__ import annotations or python>=3.10 then you can use:

if TYPE_CHECKING: ... import NonRuntimeVar my_var: NonRuntimeVar = ...

mypy and ty will still analyze use of NonRuntimeVar here, but you couldn't actually do:

NonRuntimeVar() # or isinstance(something, NonRuntimeVar)

Oh, I see, thanks for clarifying!

jonburdo

Thanks @andreyvelich for the review and all the thoughtful feedback! I believe I've addressed it. The one thing I'm not sure about is the question about docs: #186 (comment)

jonburdo · 2026-01-09T18:29:26Z

Makefile

 	@uv lock --check
 	@uv run ruff check --show-fixes --output-format=github .
 	@uv run ruff format --check kubeflow
+	@uv run mypy kubeflow/hub --exclude '_test\.py$$'


We are using ruff for linting, but it doesn't include type-checking, which we really want, so we also need mypy (e.g. if we're passing an int to str arg ruff won't catch that). The same org behind ruff is working on a type checker, ty, but it's relatively new and would still be a separate tool: https://github.com/astral-sh/ty

jonburdo · 2026-01-09T18:50:29Z

kubeflow/hub/api/model_registry_client.py

+from collections.abc import Iterator, Mapping
+from typing import TYPE_CHECKING
+
+if TYPE_CHECKING:


We want type annotations on the functions for better type-safety. LSPs will use them too (docs/checks in code editors). The if TYPE_CHECKING allows us to import things we may not have a runtime. mypy and LSPs will use the imports but if model-registry is missing we don't get an import error at this point.

Since hub is an optional dependency, we check for model-registry upon usage of the client ModelRegistryClient() rather than upon import as discussed:
#186 (comment)

Otherwise in a new env, this would error:

pip install kubeflow python -c 'import kubeflow.hub'

jonburdo · 2026-01-09T18:58:29Z

kubeflow/hub/api/model_registry_client.py

+    def __init__(
+        self,
+        base_url: str,
+        port: int | None = None,


I've added from __future__ import annotations at the top in order to allow postponed evaluation of annotations. This allows things like:

| for union

missing-at-runtime variables like return type -> RegisteredModel instead of -> "RegisteredModel"

I've double checked this works on python 3.9 by ensuring from kubeflow.hub import ModelRegistryClient works as-is. Removing the from __future__ import annotations would result in:

TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'

jonburdo · 2026-01-09T19:06:12Z

kubeflow/hub/api/model_registry_client.py

+                     The scheme is used to infer is_secure and port if not explicitly provided.
+
+        Keyword Args:
+            port: Server port. If not provided, inferred from base_url scheme:


Good idea. Maybe we can do this as a follow-up?

I'm thinking we should keep the option to use the separate port arg, but if it's not used, we should also allow users to pass it via base_url, so these are all valid and equivalent:

ModelRegistryClient(base_url="https://example.com") ModelRegistryClient(base_url="https://example.com", port=443) ModelRegistryClient(base_url="https://example.com:443")

This can also be a change made in the base developer client (ModelRegistry from model-registry package) instead of here.

jonburdo · 2026-01-12T03:11:29Z

kubeflow/hub/api/model_registry_client.py

+                 - http:// defaults to 8080
+                 - no scheme defaults to 443
+            author: Name of the author.
+            is_secure: Whether to use a secure connection. If not provided, inferred from base_url:


#186 (comment)

is_secure is needed when you want to skip TLS verification, ie you have self-signed certs in a local development environment

We will default to is_secure=True for https and is_secure=False for http, but I believe we need to allow users to disable it too (is_secure=False with https) for development (shouldn't be done in production).

jonburdo · 2026-01-12T03:12:03Z

kubeflow/hub/api/model_registry_client.py

+        self._registry = ModelRegistry(
+            server_address=base_url,
+            port=port,
+            author=author,  # type: ignore[arg-type]


This provides a default value so it doesn't have to be passed to register_model every time it's called.

jonburdo · 2026-01-12T03:14:05Z

kubeflow/hub/api/model_registry_client.py

+        name: str,
+        uri: str,
+        *,
+        version: str,


It matches what we have in ModelRegistry and provides a little more flexibility if we want to re-order args after name, uri. I do wonder if we want to make version optional in the future and support an autogenerated version string if not provided.

jonburdo · 2026-01-12T03:15:54Z

kubeflow/hub/api/model_registry_client.py

+            TypeError: If model is not a RegisteredModel instance.
+            model_registry.exceptions.StoreError: If model does not have an ID.
+        """
+        from model_registry.types import RegisteredModel


This would cause an immediate error upon import for import kubeflow.hub if the user has done:

pip install kubeflow

but not

pip install 'kubeflow[hub]'

We could opt for that. Or we could do a lazy import. I would suggest leaving it as-is though.

jonburdo · 2026-01-12T14:27:48Z

kubeflow/hub/api/model_registry_client_test.py

+        """Skip these tests if model-registry not installed."""
+        pytest.importorskip("model_registry")
+
+    def test_init_raises_helpful_error_when_not_installed(self, monkeypatch):


Sure, I've made this change. This does we are importing TestCase from kubeflow.trainer. I also have mixed feelings about this, but if it's something we want to standardize in the sdk, then I guess it works.

kramaranya

Thank you, @jonburdo!
Overall looks great to me 👍

kramaranya · 2026-01-13T16:47:29Z

.github/workflows/check-pr-title.yaml

            ci
            docs
            examples
+            hub


I see, thanks @jonburdo!

kramaranya · 2026-01-13T17:06:18Z

Makefile

 	@uv lock --check
 	@uv run ruff check --show-fixes --output-format=github .
 	@uv run ruff format --check kubeflow
+	@uv run mypy kubeflow/hub --exclude '_test\.py$$'


@jonburdo have you tried to compare ty and mypy? does it cover everything you're using mypy for?

kramaranya · 2026-01-13T17:10:33Z

kubeflow/hub/__init__.py

@@ -0,0 +1,5 @@
+"""Kubeflow Hub API."""


Can you add copyright header please to all new files?

Good catch! Added

kramaranya · 2026-01-13T17:41:56Z

kubeflow/hub/api/model_registry_client.py

+                     The scheme is used to infer is_secure and port if not explicitly provided.
+
+        Keyword Args:
+            port: Server port. If not provided, inferred from base_url scheme:


I agree with @andreyvelich, this will keep our APIs consistent for users

kramaranya · 2026-01-13T17:46:20Z

kubeflow/hub/api/model_registry_client.py

+            name: Name of the model.
+            uri: URI of the model.
+
+        Keyword Args:


Yes, I think it's configurable. I'll soon open a PR for the website and will verify it

kramaranya · 2026-01-13T17:56:13Z

kubeflow/hub/api/model_registry_client.py

+    def list_models(self) -> Iterator[RegisteredModel]:
+        """Get an iterator for registered models.
+
+        Yields:
+            Registered models.
+        """
+        yield from self._registry.get_registered_models()


We return an Iterator in Model Registry with list_models, however, we return lists for both OptimizerClient and TrainerClient in APIs like list_jobs().
@andreyvelich @jonburdo to provide consistent APIs to our users, shall we consider aligning OptimizerClient and TrainerClient with ModelRegistryClient and return an Iterator, alternatively we can return list in ModelRegistryClient?

I feel like returning the list might be a good option, with future improvements to return Iterator if users will request it.

@tarilabs @jonburdo Do you see a lot of use-cases when this doesn't work?
I don't expect that users manage more than millions of models in their registries.

Discussed in the community call today. We definitely want to keep this as a generator.

We use pagination, so eagerly fetching and returning a list would make extra API calls, and it is certainly possible to have enough entries for significant overhead.

I'm not sure I'd consider it real inconsistency if some functions in a library return a list and some return a generator - especially if it's done in a logical way based on amount of data or usefulness of evaluating lazily.

jonburdo · 2026-01-14T21:26:56Z

Okay, I've rebased and updated the code. I think I covered our discussion points!

Here is a succinct summary covering most of the points:

I changed:

replace mypy with ty (with python 3.10 as target version)
add missing copyright headers

I kept:

base_url (instead of url)
version arg (required kwarg)
docstrings as-is
return generator instead of list
is_secure bool

andreyvelich

Thanks for the updates @jonburdo!
I left a few comments, we should be good to go!
/assign @kramaranya @astefanutti @tarilabs @szaher in case you want to add more comments.

andreyvelich · 2026-01-14T23:48:56Z

kubeflow/hub/api/model_registry_client.py

+
+        Args:
+            base_url: Base URL of the model registry server including scheme.
+                     Examples: "https://registry.example.com", "http://localhost"


Please can you add example with port as well? e.g. https://registry.example.com:8888

I think we want to fix this in the developer (model-registry) client. I've created an issue for this: kubeflow/model-registry#2110

Otherwise we'll have url parsing here and then again there (in ModelRegistry)

Sounds good @jonburdo!
Please can you create an issue in kubeflow/sdk to also track this update once Model Registry client supports it upstream?

Added here: #227

andreyvelich · 2026-01-14T23:50:44Z

kubeflow/hub/api/model_registry_client_test.py

+    "test_case",
+    [
+        TestCase(
+            name="http URL infers port=8080 and is_secure=False",


Could we add a test case when port is taken from the base_url?

"base_url": "http://localhost:1234",

andreyvelich · 2026-01-14T23:51:59Z

kubeflow/hub/api/model_registry_client_test.py

+        ),
+    ],
+)
+def test_get_model(test_case, client, mock_registry):


Could we add tests for test_get_model_version and test_get_model_artifact ?

andreyvelich · 2026-01-14T23:53:59Z

kubeflow/hub/api/model_registry_client_test.py

+        ),
+    ],
+)
+def test_update_model_type_check(test_case, client):


Can you add all of these test cases to the test_update_model ? Similar to other tests, we can have one function with test cases for each public API we expose.

andreyvelich · 2026-01-14T23:54:23Z

kubeflow/hub/api/model_registry_client_test.py

+        ),
+    ],
+)
+def test_update_model_version_type_check(test_case, client):


Same suggestion to move them to the test_update_model_version

andreyvelich · 2026-01-14T23:54:40Z

kubeflow/hub/api/model_registry_client_test.py

+        ),
+    ],
+)
+def test_update_model_artifact_type_check(test_case, client):


andreyvelich · 2026-01-14T23:59:42Z

README.md

 ```

+### Manage models with Model Registry
+


Can we also point users to the Model Registry documentation which says how to install control plane: https://www.kubeflow.org/docs/components/model-registry/installation/#standalone-installation

In the future, we might also want to introduce public ConfigMap check that verifies that Kubeflow Hub control plane is available on the cluster: #221
We can do this after the initial release.

andreyvelich

Thanks for the updates @jonburdo!
/lgtm
/cc @kramaranya in case you want to add more comments.
As we discussed, we will merge this to the main branch once we release Kubeflow SDK 0.3
/hold

Add an api for model registry under a new kubeflow.hub submodule. This takes the form of a ModelRegistryClient class and provides a user-facing api in a style similar to existing Kubeflow SDKs. AI-assisted: Claude Code 2.0.58 (claude-sonnet-4-5@20250929) Signed-off-by: Jon Burdo <jon@jonburdo.com>

jonburdo · 2026-01-20T18:48:30Z

I've rebased to fix the merge conflicts. To see the conflict resolution changes only, you can use:

git range-diff 4816b1d...db12a29

It's just a slight change to pyproject.toml and changes to uv.lock

With the release of Kubeflow SDK 0.3 are we ready to merge this @andreyvelich ?

andreyvelich

Thank you for this @jonburdo!
/lgtm
/assign @kubeflow/kubeflow-sdk-team @kramaranya

kramaranya

Thank you so much for this amazing contribution, @jonburdo!
/lgtm

kramaranya · 2026-01-20T23:59:02Z

@jonburdo feel free to add OWNERS file to https://github.com/jonburdo/sdk/tree/kubeflow-hub-api/kubeflow/hub with Model Registry WG.
cc @andreyvelich

andreyvelich · 2026-01-21T01:05:13Z

/approve
@kubeflow/kubeflow-hub-team Feel free to create followup PR to add OWNERs to the kubeflow.hub sub-package.

google-oss-prow · 2026-01-21T01:05:21Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andreyvelich

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [andreyvelich]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

andreyvelich · 2026-01-21T01:33:59Z

/milestone v0.4

jonburdo · 2026-01-21T14:37:54Z

/unhold

google-oss-prow bot requested review from kramaranya and szaher December 2, 2025 01:12

google-oss-prow bot added the size/XXL label Dec 2, 2025

jonburdo changed the title ~~feat(hub): add model registry client~~ feat: add model registry client Dec 2, 2025

jonburdo marked this pull request as draft December 2, 2025 01:47

google-oss-prow bot added the do-not-merge/work-in-progress label Dec 2, 2025

jonburdo force-pushed the kubeflow-hub-api branch 2 times, most recently from fd5f82f to 33efe23 Compare December 3, 2025 00:21

jonburdo commented Dec 3, 2025

View reviewed changes

jonburdo marked this pull request as ready for review December 3, 2025 00:29

google-oss-prow bot removed the do-not-merge/work-in-progress label Dec 3, 2025

jonburdo mentioned this pull request Dec 3, 2025

Add Model Registry Client to Kubeflow SDK #59

Closed

kramaranya mentioned this pull request Dec 3, 2025

[DRAFT] Add Model Registry to Unified SDK #60

Closed

1 task

kramaranya reviewed Dec 3, 2025

View reviewed changes

jonburdo force-pushed the kubeflow-hub-api branch from 33efe23 to 7c78065 Compare December 4, 2025 02:30

jonburdo commented Dec 4, 2025

View reviewed changes

jonburdo force-pushed the kubeflow-hub-api branch 2 times, most recently from 1218458 to affcdc5 Compare December 4, 2025 16:31

jonburdo force-pushed the kubeflow-hub-api branch 2 times, most recently from 86564f2 to 854e6ba Compare December 10, 2025 13:02

jonburdo commented Dec 10, 2025

View reviewed changes

kubeflow/hub/api/model_registry_client.py Show resolved Hide resolved

andreyvelich reviewed Jan 9, 2026

View reviewed changes

jonburdo force-pushed the kubeflow-hub-api branch from 854e6ba to 7f41fa7 Compare January 12, 2026 13:53

jonburdo commented Jan 12, 2026

View reviewed changes

kramaranya reviewed Jan 13, 2026

View reviewed changes

jonburdo force-pushed the kubeflow-hub-api branch from 7f41fa7 to a8c20a7 Compare January 14, 2026 21:18

andreyvelich reviewed Jan 14, 2026

View reviewed changes

jonburdo force-pushed the kubeflow-hub-api branch 2 times, most recently from 9179042 to 4816b1d Compare January 15, 2026 21:45

jonburdo mentioned this pull request Jan 16, 2026

Parse port from base url in ModelRegistryClient #227

Open

4 tasks

andreyvelich reviewed Jan 19, 2026

View reviewed changes

google-oss-prow bot added the do-not-merge/hold label Jan 19, 2026

google-oss-prow bot assigned andreyvelich Jan 19, 2026

google-oss-prow bot added the lgtm label Jan 19, 2026

jonburdo force-pushed the kubeflow-hub-api branch from 4816b1d to db12a29 Compare January 20, 2026 18:07

google-oss-prow bot removed the lgtm label Jan 20, 2026

andreyvelich reviewed Jan 20, 2026

View reviewed changes

google-oss-prow bot added the lgtm label Jan 20, 2026

kramaranya approved these changes Jan 20, 2026

View reviewed changes

google-oss-prow bot assigned kramaranya Jan 20, 2026

google-oss-prow bot added the approved label Jan 21, 2026

andreyvelich mentioned this pull request Jan 21, 2026

feat: add SparkClient API for SparkConnect session management #225

Merged

google-oss-prow bot added this to the v0.4 milestone Jan 21, 2026

google-oss-prow bot removed the do-not-merge/hold label Jan 21, 2026

google-oss-prow bot merged commit 716448f into kubeflow:main Jan 21, 2026
14 checks passed

jonburdo deleted the kubeflow-hub-api branch January 21, 2026 16:10

jonburdo mentioned this pull request Jan 26, 2026

chore(hub): add OWNERS file to kubeflow.hub #244

Merged

1 task

andreyvelich mentioned this pull request Feb 18, 2026

Kubeflow SDK v0.4 Release #303

Open

6 tasks

Conversation

jonburdo commented Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

details

Uh oh!

github-actions bot commented Dec 2, 2025

Uh oh!

coveralls commented Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pull Request Test Coverage Report for Build 21182264396

Details

💛 - Coveralls

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kramaranya left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jonburdo left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hbelmiro Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jonburdo commented Dec 4, 2025

Uh oh!

Uh oh!

andreyvelich left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tarilabs Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

jonburdo commented Dec 2, 2025 •

edited

Loading

coveralls commented Dec 2, 2025 •

edited

Loading

jonburdo left a comment •

edited

Loading

hbelmiro Jan 14, 2026 •

edited

Loading

tarilabs Jan 9, 2026 •

edited

Loading