Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Integration of MLFlow and Other Registries Support #46

Open
Dhanunjaya-Elluri opened this issue Mar 19, 2024 · 7 comments
Open

Integration of MLFlow and Other Registries Support #46

Dhanunjaya-Elluri opened this issue Mar 19, 2024 · 7 comments
Labels
lifecycle/frozen

Comments

@Dhanunjaya-Elluri
Copy link

Kubeflow's model registry Python client supports only HuggingFace.

  • Extend this model registry to support MLFlow and other popular registries
@Dhanunjaya-Elluri
Copy link
Author

@lampajr I would like to work on this task as a part of GSoC 2024.

@rareddy
Copy link
Contributor

rareddy commented Mar 19, 2024

@Dhanunjaya-Elluri you are welcome to submit as proposal but it will be a small project. You can welcome to contribute outside of Gsoc too.

@Dhanunjaya-Elluri
Copy link
Author

Hi @rareddy, thanks for your quick reply. I already submitted proposal. But I can start looking into this right now. Do you have any suggestions to get started? For example acceptance criteria for this task.

@rareddy
Copy link
Contributor

rareddy commented Mar 22, 2024

@Dhanunjaya-Elluri if your approach is going to be similar to HF work I suggest take look that.

See this opendatahub-io/model-registry-bf4-kf#133 look at the comment I made about the abstracting API, I still believe that is the right way to develop a feature that can fit consistent API or a little variation of it if you are feeling little brave. well acceptance criteria is that works and have unit tests, an documented example.

tarilabs added a commit to tarilabs/model-registry that referenced this issue Apr 18, 2024
@pull @isinyaaa @tarilabs
[pull] main from kubeflow:main (kubeflow#46)
4e2a58c 
* Py: Fix misleading errors on missing list results (kubeflow#65)

* py: fix type annotations to return concrete types

Signed-off-by: Isabella Basso do Amaral <[email protected]>

* py: fix missing type check on empty list results

Signed-off-by: Isabella Basso do Amaral <[email protected]>

---------

Signed-off-by: Isabella Basso do Amaral <[email protected]>

* fix: OpenAPI ModelVersion shall contain registeredModelId property (kubeflow#61)

need to adapt property definition in OpenAPI
to accomodate openapi-codegen result;
according to contract (as also visible in swagger)
the ModelVersion is to contain property: registeredModelId

Signed-off-by: Matteo Mortari <[email protected]>

---------

Signed-off-by: Isabella Basso do Amaral <[email protected]>
Signed-off-by: Matteo Mortari <[email protected]>
Co-authored-by: Isabella Basso <[email protected]>
Co-authored-by: Matteo Mortari <[email protected]>
tarilabs added a commit to tarilabs/model-registry that referenced this issue Apr 18, 2024
@tarilabs
Revert "[pull] main from kubeflow:main (kubeflow#46)" due to squash
7ee172e 
This reverts commit 4e2a58c.

Missing the correct label, the automated merge did
not merge-commit but squash-commit.
Reverting.
@github-actions GitHub Actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@tarilabs
Copy link
Member

We need this (maybe reframed, rescoped) as part of roadmap.

/lifecycle frozen

@rareddy
Copy link
Contributor

rareddy commented Jul 4, 2024

@Dhanunjaya-Elluri you still interested in this? how is @mzhl1111 work related?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
lifecycle/frozen
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rareddy @tarilabs @Dhanunjaya-Elluri