Packaging options for MONAI Deploy Express

[mocsharp]

What are your preferred ways of downloading & installing MONAI Deploy Express?

• Download a ZIP package from GitHub Release page and install pre-requisites by following the README?
• Download & install via Chocolatey?
• Download & install via apt?
• Download using PyPi? And Install by using provided python script?
• Others? Please share your ideas below.

Edit: truly sorry for not setting the context!

MONAI Deploy Express is a way to run the MONAI Deploy platform on your laptop, desktop, or any other system.
It includes Informatics Gateway, Workflow Manager, Task Manager, and all of the dependencies (Mongo, RabbitMQ, MinIO, Orthanc)

What's in the package:

• A docker-compose file
• Service configuration files
• 3 sample workflow definitions
• README.md

For more details, please review #68

Edit 2:
MONAI Deploy Express runs the same services as what you would have on a production system except it uses Docker to orchestrate your MAPs.

Edition	Lite	Full
Platform	Docker	K8s
MAP Orchestration	docker plug-in	argo plug-in as default
Auth	Disabled	OAuth2
Workflow Definition	same	same
Data routing	same	same

[dbericat]

@vikashg @CPBridge @ericspod @ristoh @aihsani @aylward @AnilMistry @laurencejackson @Lucrezia-Cester @MMelQin @mjorgecardoso

Thinking on your developer workstations where you want to validate MAPs on connected with a PACS like Orthanc.

How would you prefer the experience to download and install all the components be?

[laurencejackson]

Thanks for asking @mocsharp,I think this making sure this process is simple or well documented is going to be very important in encouraging devs to package for MONAI deploy.

tl;dr: chocolatey/apt/brew/pip combo, or docker

My thoughts on the options you've proposed:

zip: I have no issues with this, but the key thing will be how difficult or intimidating the readme is to new developers.

chocolatey, apt (+brew): In principle I think this is a great option. I guess the issue with package managers like these are that they won't work for all, and we'll need to maintain multiple releases on all the managers. If this can be easily automated then great!

pip: PIP may be a bit better than the above since python is less platform dependent than the packagers above. But if developers want to work with other languages this might be a barrier.

Would we be able to install and release through Docker? This would probably be my preferred option, setting up monai and it's supporting services with a docker-compose script would be amazing! The one potential issue with docker that I see would be that the Docker Desktop (Mac + windows) license doesn't allow commercial work for large organisiations.

[aylward]

Assuming we're talking about relatively low resource solutions (can be run on a desktop with a modest GPU and featuring python scripts with simple GUIs in tkinter/pyscript/... and a small amount of other bundled resources, e.g., dcm2niix), I use two methods for delivering them, depending on the platform and skill of the user:

1. PyPi
2. PyInstaller+Innosetup (or equivalent) to create a self-installing executable that doesn't require a pre-installed python (or anything pre-installed)

The nice part is that technology, workflow, and skill to deliver both of these solutions is nearly the same and represents a nice continuum.

1. Make the base libraries, code, and python script available via pypi. This is great for those with even just basic python knowledge and comfort with typing commands. It allow me to easily share updates with them (create a new pypi revision), and there is extensive documentation on using pypi for most platforms (windows and anaconda is still intimidating to some).

2. For those not comfortable with pip (particularly if on Windows without a python installation), use pyinstaller to create complete stand-alone executables for installing and running the script. Using the pip installations from (1), all that is needed is a simple config file, perhaps a few hooks to gather data and other libs to be included, and innosetup or other tool for making a self-installer. Within 30 mins your python environment + scripts becomes a self-installing executable for Windows (or Mac or Linux). You can even setup windows services and other tricks this way. I keep mentioning Windows since that is still the dominant platform in clinicians (with macs that come with python being second).

For solutions that require more resources (large machines, big GPUs, lots of data, etc.) there typically some associated sysadmin support (even if fleeting) and setup starts involving permissions, hospital policies, ... so creating an appropriate linux environment and services (or whatever) becomes reasonable effort.

s

[ericspod]

My preference is PyPI first, conda as well if helpful, Docker images for sure which aren't difficult to put together if things can be installed with pip, and PyInstaller if we can get it to work with the various libraries we'd need to use. I don't recommend apt/chocalety/brew because they often need installing, need command line functionality, need permissions, and all too often make a mess of the host system.

My expectation is that users have their own system with Anaconda/Miniconda installed, or some other user-installed Python environment. They can run pip with the ability to undo any damage through uninstall or recreating the environment. They may be in a virtual environment like Colab where they have no permissions but can still run pip, but will not be able to run a downloaded executable or docker container for architectural and/or security reasons. Many HPCs would be similarly restricted in what the user can do.

[mocsharp]

@ALL Sorry that I have forgot to mention, MD Lite is a docker compose file.

Please see #68

[aylward]

Is the goal "Lite" for developers or "Lite" for users?

[mocsharp]

@vikashg @CPBridge @ericspod @ristoh @aihsani @aylward @AnilMistry @laurencejackson @Lucrezia-Cester @MMelQin @mjorgecardoso sorry for not setting the context! Please share your thoughts again.

[MMelQin]

The Lite version has some key difference from the full version, mostly non-functional, e.g. no built security so no access control nor data protection at rest, Admin privilege required to stand up the system (since running docker from within docker needs the admin privilege to bind the docker socket, scalability is not built-in nor implied but it should suffice for a few workflows, the way the MONAI Apps are hosted with be different, namely using docker config instead of Argo template for the task etc. The doc should and must make this clear.

With this said, as far as workflow definition and from the users' perspective, integration with external "PACS" and performing inference is the same as in the full version.

[dbericat]

Lite sweet spot is developers that want to run MAPs on their workstations, managed by them. Easy to get started, faster time to validate your applications. Gather support from other teams and business stakeholders before investing further, etc.

This means no Kubernetes, no microservices scaling horizontally, no production features at the infrastructure layer, like Ming explained.

But it does use the same MONAI Deploy core services (same Informatics Gateway, same Workflow Manager, same dependencies).

So it covers both 1 and 2, Stephen. Bugs identified in them will save time in production full version. But infra, networking, storage, etc. won't.

The goal is to drive adoption, while learning about the platform components. But the end goal is to move to a full blown production system, like what the AI Centre is doing with AIDE, using the same components running as cloud microservices.

Makes sense?

[ericspod]

Lite looks like a good solution to run a deploy environment on a local minimal environment. Rapidly testing a deploy environment of any sort is going to aid in development and experimentation. We'll have tutorials on using it eventually but a step-by-step guide that follows the story from creating a MAP to deploying it with this environment will go a long way to making it accessible to less advanced users.

The configuration files in #68 have a lot of details that are important for the environment but these will be off-putting to newer users that aren't familiar with these technologies. Once again I am thinking of the simpler use case for a student or researcher but there's only so much simplification we can do of course. Some of the fine details that are important will have to be described more precisely I feel, such as why curl is used in places and what it's doing as a lot of people aren't familiar with it.

[MMelQin]

I am also considering the "bottom up" path along in addition to this "top down" (from Full to Lite):

• App SDK provides CLI to run and test a MAP for a single input, and code examples are provide to make a MAP process multiple inputs or be a long running process, though limited to limited to file input (DICOM Part 10 files)
• Scripts have been provided to run MAP as an opaque container without installing the App SDK or its CLI, which will help users to run MAPs on other platforms
• Next up will be a simple hosting service to run 1(one) MAP
  • this process receives and exports DICOM instances using DICOM DIMSE
  • it runs only one MAP for simplicity, and will use Docker SDK
  • implementation can be new, based on pynetdicom, or a simplified MONAI Deploy Informatics Gateway
• Also in consideration is a plug-in to Orthanc, which is popular in research community
  • rely on Orthanc's proven DICOM capability
  • plug-in to handle DICOM ingestion event to trigger MAP for a study/series
  • plug-in may be able to handle processing of existing study/series
  • ISSUE is that Orthanc plug-in has GPL license

[dbericat]

Love this @MMelQin . Are these captures on issues already? Links? Otherwise let's make sure they are there and assign them to a release, either 0.5 or 0.6. Let's discuss!