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]: Adapt logic for model serving creation in new projects #1941

Closed
lucferbux opened this issue Oct 10, 2023 · 4 comments · Fixed by #2012
Closed

[Story]: Adapt logic for model serving creation in new projects #1941

lucferbux opened this issue Oct 10, 2023 · 4 comments · Fixed by #2012
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. 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

Adapt the logic of how we display model serving technology in new projects

Dependency issue

Itemized goals

  • Add logic to detect the project is not currently set up with any model serving technology
    • If the project lacks the modelmesh-enabled: ... annotation it will present an empty view (see the following options)
  • If both modelmesh and kserve are enabled, display the page to select the technology [Story]: Empty State platform selection #1944
  • If only kserve is enabled display the kserve project view
  • If only modelmesh is enabled, display de modelmesh project view

Aspects continued elsewhere

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. labels Oct 10, 2023
@lucferbux lucferbux added the feature/model-serving Model Serving Feature label Oct 10, 2023
@lucferbux lucferbux moved this from Untriaged to Dev To do in ODH Dashboard Planning Oct 10, 2023
@lucferbux
Copy link
Contributor Author

There are a few edge cases that I would want to cover:

  1. If we ended up having detection of the serving platforms and one of them is failing, do we show a message error?
  2. If somehow the cluster ends up with no serving platform selected, what's the fallback? (i assume kserve)
  3. If kserve is the only one selected but the controller is failing, I assume we'll show an error message right?

cc @andrewballantyne @christianvogt @vconzola

@andrewballantyne
Copy link
Member

no1 & no3 We are not hunting down controller state... get everything from the DSC's .status, such as conditions and the reason. We can either get from it via the k8s pass-through API (if opendatahub-io/opendatahub-operator#588 is done -- unlikely for this work) or we use a shim layer on the Node Server and get it through the Service Account.

no2 can favour KServe as a fallback until we decide how best to handle both being turned off -- naturally fall back on an error if it's not installed. We have a "model serving" flag, and we are adding "model mesh" and "kserve" flags... so it's a bit of a mess. We need to clean this up but this should be on your work to do so.

@lucferbux lucferbux assigned lucferbux and unassigned lucferbux Oct 19, 2023
@lucferbux lucferbux self-assigned this Oct 22, 2023
@lucferbux lucferbux moved this from Dev To do to Dev In progress in ODH Dashboard Planning Oct 23, 2023
@lucferbux lucferbux assigned DaoDaoNoCode and unassigned lucferbux Oct 24, 2023
@DaoDaoNoCode
Copy link
Member

Most of the functionality in this ticket is done in #2012, we just need #1943 to be done to apply the label modelmesh-enabled: 'false' to the project and we could close this ticket.

@DaoDaoNoCode
Copy link
Member

After checking, I think we can actually safely close this ticket with #2012, all the logic could be addressed when the deploy KServe model feature is finished.

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. priority/high Important issue that needs to be resolved asap. Releases should not have too many of these.
Projects
Status: Done
Status: No status
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants