Currently, Karabo doesn't work properly with Singularity containers. The issue is, that in a Singularity container, you're the same user which has launched a container, which is a different user than the one who created the image. This leads to read-only file-systems on each directory which is not mounted. This creates a situation, where you would have to tell a user, which is using Singularity, to use it in a very specific way, which is usually not what is desired.
Therefore, I suggest to unify each IO-operation with the filesystem using FileHandler. There you can ensure, that IO-operations should happen at a location, where the read-only constraint is not present.
In addition, I think it would also be a good idea to differentiate between long- and short-term cache, and implement a good caching strategy. I think this is important, to ensure that downloaded objects are accessible in different processes (e.g. mpirun) and runs (e.g. multiple jobs), so that you don't have to download it for each time & can download it into a writeable-location. At best, something that gets mounted, so you don't lose it after a container is destroyed.
Currently, Karabo doesn't work properly with Singularity containers. The issue is, that in a Singularity container, you're the same user which has launched a container, which is a different user than the one who created the image. This leads to read-only file-systems on each directory which is not mounted. This creates a situation, where you would have to tell a user, which is using Singularity, to use it in a very specific way, which is usually not what is desired.
Therefore, I suggest to unify each IO-operation with the filesystem using
FileHandler. There you can ensure, that IO-operations should happen at a location, where the read-only constraint is not present.In addition, I think it would also be a good idea to differentiate between long- and short-term cache, and implement a good caching strategy. I think this is important, to ensure that downloaded objects are accessible in different processes (e.g. mpirun) and runs (e.g. multiple jobs), so that you don't have to download it for each time & can download it into a writeable-location. At best, something that gets mounted, so you don't lose it after a container is destroyed.