App SDK Migration (to depend on Holoscan SDK)

[MMelQin]

This is a large change set to review, for the reason that these are changes are to base the App SDK on Holoscan SDK and incremental merger into main is not feasible.

Major changes:

• Exposing Holoscan SDK modules as monai.deploy ones by creating a similar sub module structure and importing Holoscan modules within each
• Updated MONAI Deploy App SDK native modules/classes to the new core and other modules
• Updated the example applications
• Updated the Jupyter notebooks
• Updated Doc changes

Example apps can be tested directly, though the model file and test files must be downloaded and staged local, with environment variables set to point to the input, model, and output folders.

Alternatively, the example apps can be tested with the Jupyter notebooks, as they include the steps to download the test data and set environment variables for input etc. However, please avoid 02_mednist_app-prebuilt as it pulls the code from the main branch, hence not going to work. Also, for the notebooks, the MAP packaging step needs to be modified to provide the App SDK Wheel file built in this branch, with the --monai-deploy-sdk-file option, as well as setting --sdk-version 0.6.0; this is needed because the Packager would otherwise pip install the App SDK from PyPi, which obviously does not have v0.6.0 App SDK yet. So, to prepare the Wheel file

• checkout this branch, and cd to the project root
• create and activate venv
• ./run setup
• ./run build
• In the dist folder, find the Wheel file, e.g. monai_deploy_app_sdk-0.5.1+18.gf829a6c-py3-none-any.whl
• For the Packaging step of all the Jupyter Notebooks, add the versions and sdk file, e.g.
  monai-deploy package my_app -m {models_folder} -c my_app/app.yaml -t {tag_prefix}:1.0 --platform x64-workstation -l DEBUG --sdk-version 0.6.0 --monai-deploy-sdk-file {sdk_wheel}

Note:

Sonarcloud has complaints about many commented out code in the example apps, but they were left there for good reasons. It also complains about duplications, which are unavoidable because the example applications need to implement the same or similar code.
Unit test coverage is low, though the Jupyter notebooks are for functional and integration tests which exercise the App SDK more thoroughly.

Side Note:

Not impacting the review and such, just a bit of the history of this branch.

This pull request is from a dev branch which was merged onto from a prior migration dev branch with all the commits squashed, as seen below

$ git checkout main
$ git pull
$ git checkout -b mqin/v0.6_from_0.5.1
$ git merge --squash mqin/sdk_migration
$ git commit -s
$ git push --set-upsream v0.6_from_0.5.1

[vikashg]

Hi @MMelQin
Quick question as I am reviewing this. Did we change how app().run() functions. I remember in the previous version you can do the following for setting the input directory as app().run(input=path_to_some_input_dir). But now we cannot do this, even though the Application has an argument input.
I tried the simple_imaging_app in the examples and it works fine. But when I try to change the input directory to something else as

app().run(input='./input2')

I get the following error

(monai-deploy-test) gupta@DIGI1036734:~/disk/Tools/CodeReview/monai-deploy-app-sdk/examples/apps/simple_imaging_app$ python app.py 
Traceback (most recent call last):
  File "app.py", line 78, in <module>
    App().run(input='./input2')
TypeError: run(): incompatible function arguments. The following argument types are supported:
    1. (self: holoscan.core._core.Application) -> None

Invoked with: <holoscan.Application: name:>; kwargs: input='./input2'

But the command line works just fine

(monai-deploy-test) gupta@DIGI1036734:~/disk/Tools/CodeReview/monai-deploy-app-sdk/examples/apps/simple_imaging_app$ python app.py -i ./input2
sample_data_path: input
[info] [gxf_executor.cpp:210] Creating context
[warning] [gxf_extension_manager.cpp:132] Unable to load extension from 'libgxf_bayer_demosaic.so' (error: libnppicc.so.11: cannot open shared object file: No such file or directory)
[info] [gxf_executor.cpp:1595] Loading extensions from configs...
[info] [gxf_executor.cpp:1741] Activating Graph...
[info] [gxf_executor.cpp:1771] Running Graph...
[info] [gxf_executor.cpp:1773] Waiting for completion...
[info] [gxf_executor.cpp:1774] Graph execution waiting. Fragment: 
[info] [greedy_scheduler.cpp:190] Scheduling 3 entities
Number of times operator sobel_op whose class is defined in sobel_operator called: 1
Input from: input, whose absolute path: /home/gupta/disk/Tools/CodeReview/monai-deploy-app-sdk/examples/apps/simple_imaging_app/input
Number of times operator median_op whose class is defined in median_operator called: 1
Number of times operator gaussian_op whose class is defined in gaussian_operator called: 1
Data type of output: <class 'numpy.ndarray'>, max = 0.3480125635568479
Data type of output post conversion: <class 'numpy.ndarray'>, max = 88
[info] [greedy_scheduler.cpp:369] Scheduler stopped: Some entities are waiting for execution, but there are no periodic or async entities to get out of the deadlock.
[info] [greedy_scheduler.cpp:398] Scheduler finished.
[info] [gxf_executor.cpp:1783] Graph execution deactivating. Fragment: 
[info] [gxf_executor.cpp:1784] Deactivating Graph...
[info] [gxf_executor.cpp:1787] Graph execution finished. Fragment: 
[info] [gxf_executor.cpp:229] Destroying context

[MMelQin]

@vikashg Thanks for reviewing the pull request. The run method does not have the desired behavior that we had in the App SDK 0.5 and earlier, basically this is saying that the input and output folders can NOT be passed in via this method. Also, on the application does not parse command line arguments for setting the input and output folders, either. This is mostly due to the underlying Holoscan SDK.

The environment variables are now used to define the input and output folders, though the parsing of such is still not the built-in functionalities of the base Application class, and each derived Application class needs to explicitly create the app context to parse them.

[vikashg]

Thanks @MMelQin. I am going over it. Few things are interesting and definitely new like Fragments and Condition. So I am going over that on the holoscan documentation.

[MMelQin]

Thanks @MMelQin. I am going over it. Few things are interesting and definitely new like Fragments and Condition. So I am going over that on the holoscan documentation.

Thanks @vikashg . Yes, the underlying Holoscan SDK does introduce some new capabilities while losing a few for the time being, e.g. decorators for I/O spec and dependencies, and auto-mapping of file I/O for the app.

The Application class derives from Fragment, while an application implementation can also have multiple concrete fragments, enabling the app to be run on multiple nodes, each with specific fragment(s). Right now, none of the examples makes use of this.

The Condition is a very useful, allowing the Operator class to define certain input as optional, which does not require the actual input at runtime before it can start executing. Similarly, a output can be defined as "dangling", meaning downstream receivers are optional. This makes the Operator class implementation much more flexible.

I plan to have a migration guide as part of the release note to highlight the few main changes.

[vikashg]

Thanks Ming It looks good to me. Some of the issues I encountered I already mentioned to you. But generally looks great.
Thanks for the amazing work.

[MMelQin]

Thank you so much @vikashg for the approval. For the enhancement suggestions, we'll create new issues to address them in the coming releases.

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
36 Code Smells

No Coverage information
7.6% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint