Model initializer does not work with S3

[axsaucedo]

This was fixed for Kfserving in the main repo with kserve/kserve#213, but it seems the issue still exists when using the pre-packaged model server

[axsaucedo]

@cliveseldon woudl this require updating to the latest Storage.py file from KFServing?

[ukclivecox]

Yes we should stay aligned with Storage.py in kfserving

[ukclivecox]

Needs to be retested

[ukclivecox]

Explore other libraries to replace kfserving library.

[adriangonz]

Apache libcloud could be a good alternative worth exploring. One of its caveats is that it may support too many things though.

[axsaucedo]

moving discussion into #1028. Stil keeping open as this is still an issue

[axsaucedo]

Currently a PR has been opened to be able to provide default access to public S3 files kserve/kserve#589

[axsaucedo]

As a current fix, it's possible to circumvent this by creating a secret in the same way as the Seldon Docs suggest, adding an S3_ENDPOINT key with the value "s3.amazonaws.com".

[axsaucedo]

The change has been landed in the KFServing repo - @cliveseldon @ryandawsonuk what would be the best way to reflect that change into the initContainer we use? Would there be a way to do it before the next KFrelease? Or when is the next release?

[ukclivecox]

The change has been landed in the KFServing repo - @cliveseldon @ryandawsonuk what would be the best way to reflect that change into the initContainer we use? Would there be a way to do it before the next KFrelease? Or when is the next release?

Only if we create our own image and use that in Operator I think?

[axsaucedo]

Got it! Ok, I think we can use the walkaround until the new KFServing image comes out if we don't want to go through creating a new image

[ryandawsonuk]

I guess kserve/kserve#589 is the fix (just linking for reference)

[axsaucedo]

Correct. Closing this as it's now addressed in the next version of kfserving, and we'll be diving further in #1028.