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.

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

[Story]: Add logic to detect if kserve or modelmesh are installed #1946

Closed
lucferbux opened this issue Oct 10, 2023 · 3 comments · Fixed by #1990
Closed

[Story]: Add logic to detect if kserve or modelmesh are installed #1946

lucferbux opened this issue Oct 10, 2023 · 3 comments · Fixed by #1990
Assignees
Labels
feature/model-serving Model Serving Feature kind/story A user story for larger work. Should always be referenced by a "tracker" labelled issue. needs-info Further information is requested from the reporter or from another source priority/high Important issue that needs to be resolved asap. Releases should not have too many of these.

Comments

@lucferbux
Copy link
Contributor

lucferbux commented Oct 10, 2023

Goal

Add a logic to detect if both kserve and modelmesh are installed in the cluster

Dependency issue

No dependencies

Itemized goals

  • Add a custom logic to detect if kserve is installed in the cluster
  • Add a custom logic to detect if modelmesh is installed in the cluster

This issue is dependant of #1979

Aspects continued elsewhere

No response

Mocks

No mocks

@lucferbux lucferbux added priority/high Important issue that needs to be resolved asap. Releases should not have too many of these. kind/story A user story for larger work. Should always be referenced by a "tracker" labelled issue. feature/model-serving Model Serving Feature labels Oct 10, 2023
@lucferbux
Copy link
Contributor Author

@danielezonca @Xaenalt @andrewballantyne @christianvogt This is one of the technical challenges we've been discussing in the docs, is there a way to figure out if either kserve or modelmesh are installed outside of the CRDs? We need to detect each of them.

@andrewballantyne
Copy link
Member

DSC will have the values. opendatahub-io/opendatahub-operator#588 -- this is not likely to be done in time, so we will make a shim layer in our backend to get the Service Account to pull them. The .status of components installed will have your answer.

@lucferbux
Copy link
Contributor Author

Ok, so we can have a layer for this release to check the status of the controller, and add a follow up to refactor it with the DSC values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature/model-serving Model Serving Feature kind/story A user story for larger work. Should always be referenced by a "tracker" labelled issue. needs-info Further information is requested from the reporter or from another source priority/high Important issue that needs to be resolved asap. Releases should not have too many of these.
Projects
Status: Done
Archived in project
Status: No status
2 participants