Matteo Mortari

> @tarilabs I created a PR on your repo branch [tarilabs#2](https://github.com/tarilabs/model-registry/pull/2) Can you test it in your cluster and verify that it resolves both REST and gRPC routing without conflicting...

Thank you @dhirajsb for the amendment in linked PR: https://github.com/tarilabs/model-registry/pull/2#pullrequestreview-2081384540 Tested with: ``` export KF_TOKEN="$(kubectl -n default create token default)" curl -H "Authorization: Bearer "$KF_TOKEN http://localhost:8080/api/model_registry/v1alpha3/registered_models ``` (no path prefix...

I concur with all @rareddy points, +1

With the MR python client rebase on REST (https://github.com/kubeflow/model-registry/pull/152) this appears to no longer be needed, so we're going to close this. For more information: https://github.com/kubeflow/model-registry/issues/181

drafting so far: > What version of Notebooks would you like to include for the 1.9 release? no specific version required, there is a MR Python client on PyPI: https://pypi.org/project/model-registry/...

/assign @tarilabs

updated drafting so far: > What version of Notebooks would you like to include for the 1.9 release? no specific version required, there is a MR Python client on PyPI:...

With MR part of KF 1.9: https://blog.kubeflow.org/kubeflow-1.9-release/#model-registry , resolving this tracker. The next roadmap tracker can be found at: - https://github.com/kubeflow/model-registry/issues/175

> If you confirm this is a valid issue, I can try to send a PR to fix it. I'm a bit perplexed why it didn't return you `openapi.Error` 🤔...

btw, > Also, for some errors, the "code" is being empty and not populated with error code. I'm able to reproduce this with error 500 (running the same post twice)....