abstracting model downloads and file-normalization to models dir

[Gregory-Pereira]

Changes:

• /models
  • models should be downloaded from one place, the Makefile in the /models directory
  • models directory should house all models instead of the various model_server directories
• /model_servers
  • downloads will be now be called from the a local ms make target which will call download-model with some prepathed information for tests, users responsible for their own models.
  • you should be able to test with all env variables, REGISTRY, IMAGE_NAME, MODEL_NAME, MODEL_PATH and PORT
  • instituted common directory for all model_servers for building, running, running tests, etc.
• /.github/workflows
  • github workflows should call Makefiles for 2 reasons:
    • --> increase testing coverage
    • --> test how we expect users to interact with the repo

[Gregory-Pereira]

Its RFR @rhatdan @sallyom @lmilbaum

[lmilbaum]

One comment caught my eye. ghcr.io is used for testing the artifacts before they are promoted to quay.io. Hence, would you mind checking that the push pipelines are pushing the model servers container images to ghcr.io. I think that one is broken. Probably caused by the changes I merged yesterday.

[Gregory-Pereira]

Changes since last review:

• reworked model_servers to use a common Makefile
• remove mode.file normalization / obfuscation in favor of actual model name
• add logging

Just going to make sure the readmes line up with these changes, conflicts are resolved and tests passes and then I will tag people for re-review

[sallyom]

We want to keep the model-servers separate from models - we'll either volume mount a model as an init container from a containerized model, as the quadlet pod yamls are doing now, or from a host-filesystem volume mount as podman-desktop AI Lab does with the sample applications - this is to keep everything as pluggable as possible at both build time and runtime.
We made the change to use the generic model.file instead of the actual model name for the same reason, to be more flexible & pluggable - with the host filesystem mount, this makes a bit less sense but the source of truth is the Containerfile in this case, where you clearly document where & which model is being downloaded. (With containerized models, you can also show this with image metadata). These are also sample recipes and it's assumed that they won't be lifted exactly as/is into production, but the purpose is to provide a clear example of how to set up different AI applications to build on.

[Gregory-Pereira]

We want to keep the model-servers separate from models - we'll either volume mount a model as an init container from a containerized model, as the quadlet pod yamls are doing now, or from a host-filesystem volume mount as podman-desktop AI Lab does with the sample applications - this is to keep everything as pluggable as possible at both build time and runtime.

For the most part this PR keeps with this isolation, that being said I will need to adapt it to the new "model-as-a-container" paradigm, but ill try to rework it to support both.

We made the change to use the generic model.file instead of the actual model name for the same reason, to be more flexible & pluggable - with the host filesystem mount, this makes a bit less sense but the source of truth is the Containerfile in this case, where you clearly document where & which model is being downloaded. (With containerized models, you can also show this with image metadata).

I am all for this concept of normalizing as much as we can to make models easily swappable, but I also feel that @MichaelClifford did have some good points about not calling it model.file. Personally, since we already have to specifiy the name of the model I dont think we lose anything by having the model mounted at /standard/mount/path/<model-name> but I would like to hear more takes on this.

[Gregory-Pereira]

holding this to focus on the funcitonal tests