Open piotrpdev opened 11 months ago
You could provide a local model back in #18 (piotrpdev/azureml-model-to-edge@626d5a5) but that was replaced for the S3 method (and also Git in #57 soon).
I wonder -- if this is a PoC, shouldn't it showcase all methods? Have three (or how many needed) models and applications, one with model in the git, one in S3 pulled in in build-time, and one in S3 pulled in in run-time? Unless we have a strong reason to avoid any of those approaches, we shouldn't be replacing them, we should be adding the new options.
And in documentation explain how they differ.
Ideally a single task should handle getting the model and take some input for how e.g. using Git, S3, Azure, PVC (local), etc.
Overall though, this is not Edge-specific, is it? You might want something like that in the general Open Data Hub case as well.
we shouldn't we replacing them, we should be adding the new options.
I agree, I think I removed the local model method by mistake or assumed we weren't going to use it at the time.
You might want something like that in the general OpenDataHub case as well.
Can you elaborate on this please?
The various approaches to connecting models to runtimes might go to whatever demos / guides / learning materials that we have about using Open Data Hub and building pipelines there. We we have a place to carry the information outside of this ai-edge
repo, we wouldn't need to focus on the wealth of options here.
I'm sorry if I didn't make it clear enough, but for the issue to be resolved the pipelines need to be able to use a model from any PVC. Ideally this means we:
(I updated the issue A/C to reflect this)
Description
You could provide a local model back in #18 (https://github.com/piotrpdev/azureml-model-to-edge/commit/626d5a5c85ff8c5cdd4019714dce91fe1c1b7751) but that was replaced for the S3 method (and also Git in #57 soon). Ideally a single task should handle getting the model and take some input for how e.g. using Git, S3, Azure, PVC (local), etc. Modifying our existing
kserve-download-model
Tekton Task is probably best for this.Since no downloading needs to actually be done for the PVC (local) scenario, you could maybe just skip the
kserve-download-model
Task all together using a Tektonwhen
guard. However, I think modifying the Task to move the model from the provided PVC to thebuildah-cache
workspace is better, especially since we're probably going to make eachPipelineRun
use its own PVC soon (usingvolumeClaimTemplate
).The PoC phase two requirements specify using a model stored in a PVC as a 'P0: must have' [1]. When RHODS integration and the new Model Registry [2] comes into play this will probably be an important feature.
A/C
oc cp
azureml-container-pipeline
still works when using: