Hey Marco, I had uploaded the models there back in the days:

Thanks. I think restricted access to code and models makes a big difference in the sense of preparatory work, code cleaning. model licensing etc.. ;) So that's why we thought it would be good first step to resolve all technical issues. Moving code and models to a public location would be another thing then.

Ok, but this makes not a big difference, right?
Here's what I think would be good for us:

• A single Dockerfile build-able without any local files
• The needed source-code should be downloaded via a direct git clone within the Dockerfile
• Internal usage would allow to pass credentials as build-args to git
• Models should be downloaded via curl during the build-process as well
• There should be two stages:
  1. Download and build source-code + download and unzip models
  2. Execution environment (incl. the models) - but without build dependencies, build tree etc

Thanks @schererj , maybe one information was missing: as a first step we thought about making this build-able internally, so as part of the Kaapana/Dcipher-internal repo (option 2 in my comment above from March 25th)

The problem is the MBI branch, which is afaik not public.
If there is a working Dockerfile, which can be publicly build, I'm happy to include it.
Additionally the models need to be put somewhere to be downloaded (also public in this case).
Hope this helps.

@norajitr thanks for the follow up. Could you attach the two (?) Dockerfiles here and post the network drive path? Maybe someone else from Kaapana (internal) could have a look then, too.

After talking with Marco, I have looked for the whereabouts of dockerfiles (liver-mri and multiorgan-seg), working commits for MITK (a0dedffb74d) and for MBI-builds (56ad5bf7064) and trained models. @schererj: I sent you this information via email in October 2020, and shared the trained models on the network drives. Can you confirm? What information do you need to keep the shape models operational?

Checked again, no idea how to fix it. The Browser seems to remove the mime type of the object... so either i remove the file check completely or we find a way of how the browser can be enabled to deal with mime types:

Is this ticket then realy priority "wishlist"? (Stefan put it there because it was not triaged at all) A solution (what ever it maybe) seems to be more relevant to Kaapana then just wishlist.

Discussion from Tech meeting (Hanno, Klaus, Marco)

I was able to reproduce the error. I will take a look

after tests of the system, the problem might be at the airflow part, this has to be tested

check with microk8s - kata microk8s current system

Not sure if this is related: