Let pipelines use model from PVC

[piotrpdev]

Description

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). 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 Tekton when guard. However, I think modifying the Task to move the model from the provided PVC to the buildah-cache workspace is better, especially since we're probably going to make each PipelineRun use its own PVC soon (using volumeClaimTemplate).

Isn't downloading from Git enough?

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

• Provide template PVC file which uses best practices
• Easy and documented way of uploading a local model to the PVC e.g. using a ubi9 pod and oc cp
• Have a step/task that can copy the model from one PV (e.g. one being used by a Jupyter Notebook) to the PV/workspace being used by the pipelines.
• azureml-container-pipeline still works when using:
  • PVC (local model)
  • S3
  • Git

[adelton]

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.

[piotrpdev]

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?

[adelton]

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.

[piotrpdev]

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:

1. Provide a PVC template along with a way to upload a local model to it (like Local model upload to PVC #115)
2. Have a step/task that can copy the model from one PV (e.g. one being used by a Jupyter Notebook or 1.) to the PV/workspace being used by the pipelines.

(I updated the issue A/C to reflect this)