implement the chassis explainability and drift output architecture.

In general, the code needs a refactorization. One of the firsts steps could be moving the hardcoded variables like https://github.com/modzy/model-converter/blob/main/builder_service/service/app.py#L83 to a config file

update chassis to build containers that run on arm architectures.

We need to develop documentation both for users who want to install and run chassis as is ... and for developers who want to contribute to chassis. The installs and setups here are different so that Kaniko can run locally on a machine for the devs.

Suggestions so far:

• Open Model Interface
• Containerese
• Punnet.ml
• Chassis.ml

Suggest we go with Punnet.ml for the sake of picking one and making progress ;) but open to alternative guidance!

It could give you more status than just Not finished yet. Try again later

see: https://github.com/modzy/model-converter/wiki/Design-Doc#key-interfaces

@philwinder to work with @carmilso to develop core interfaces:

• Model layer (MLFlow)
• API layer
• Artifact layer

• write abstract to go with slides
• Luke submit to MLOps.community - got meetup talk on August 25! 🎉
• can Modzy marketing team submit to some meetups?

Readme suggestions for chassis github: 1. Instructions for data scientists to get started 2. How to install/run it 3. How to deploy it for development/contribution?

Nathan will get Carlos access, Carlos please tell Modzy team what your PyPI username is.

create an architecture design that allows for users to provide drift and explainability results to outputs of their chassis packaged models.

There are some arguments to be passed to Kaniko that may be interesting to try

Nathan has kindly agreed to write some text about the OMI vision for the website

https://github.com/modzy/docs-openmodelinterface

We'll do this ASAP now :-)

Expected first draft week of 7/5

Saumil will ask Brad to do it

Do this after modzy v2 api is ready so that we can test pushing to docker hub and then manually test in modzy after that.

Make a list of most popular output configurations and ensure that examples exist in the chassis repo. output only, output + explainability, output+ explainability + drift, also across a DL and standard model representation.

Add a section in docs to point reader to examples.

All "listening engines" should be included in a container image by default (later: input to builder could subset this).

However, which one actually runs should be selected by an env var.

@carmilso I'll update you about the discussion on this

cloud providers like AWS, Azure, etc. provide AutoML capabilities that create models in standard model artifact formats.

This issue is about adding the ability to chassis for ingesting AWS and Azure model artifacts and producing containers with the models embedded in them.

At the moment, final image weighs around 691MB. This is due to the fact that full python lib binary is copied to environment folder when packaging conda (so you don't need to use a docker image with python already installed). This python binary weighs 462MB, which represents almost the 70% of the whole image.

It would be needed to find some way to not copy the python binary and use the one from the system so that we were able to leverage a docker image like python:3.8-slim, that only weighs 114MB. Doing this we could end with an image of 343MB, which is half of what we have now.

Carlos is doing this now.

• tutorial showing how to do it given a modzy installation
• video showing how it works & upload to youtube and embed on site

Add Apache 2 license

Then ping Nathan to rename & open source it

This is done - Nathan to hit the button to open source it :-)

Chassis needs an easy UI that will gather all the information needed for the SDK's "publish" action. THe UI is envisioned to be accessible from the chassis service and can thus be used to kick off an image creation job.

@DHolmanCoding / @saumil-d can you share your example of how this can be done with MLflow please?

Test that this works with the new containerizer (when you define the MLflow model). Try this out with the stack here: https://testfaster.ci/launch?embedded=true&repo=https://github.com/combinator-ml/terraform-k8s-modelconverter&file=examples/testfaster/.testfaster.yml

Currently, input needs to be valid JSON and needs to be able to be directly cast to NumPy array. We should remove these requirements and generalize the input format.

Currently chassis containers only make 1 inference call per input.

need to design an architecture to support true batch processing and error handling in a domain that includes multiple inputs.

Issue covers needs for local testing of MLFlow models before packaging.

Issue has multiple tasks

• add the ability for a user to supply an input file locally for testing.
• add the ability for chassis-sdk to convert the input to a byte array.
• add the ability for chassis-sdk to push byte array through MLFlow model and report results.

At the moment we are using a volume to share the data that Kaniko needs between chassis pod and Kaniko job. This is the directory that is copied. It contains all the files required to build the image that contains the model sent by the user: https://github.com/modzy/model-converter/tree/mlflow/builder_service/flavours/

Kaniko can be leveraged from a local docker install. This issue is about updating chassis so that it can run locally without the need for a Kubernetes installation.

Modzy offering to host a copy of chassis to remove this burden from users.

Issue will remain open, but deprioritized

Including the Python SDK (chassisml)

Hi,
When I click the "Launch Test Drive" button at chassis.ml, after logging in I am taken to a page that says "Build VM Image", "Allocate Lease" and "Booting VM". Nothing else is on there and nothing seems to be happening. Is this expected behavior?
Thanks

https://github.com/modzy/docs-openmodelinterface

• review chassis.ml
• work on OMI site
• collaborate with Seth