Closed jourdain closed 5 years ago
Adjusted! How does it look now? The one change I didn't do is 1, because it doesn't hurt to have it there. If someone has issue with the extra files they can open a PR. How does it look for 2 and 3?
Looks great. But maybe with singularity, we may just want to start one instance of ParaView Visualizer (or another pvw app) to connect to? As opposed to have a service where many users can connect to like we do with docker?
In which case Apache and the launcher are not needed and write access is not required at all.
What do you think? But that also mean the user that want to use such image aim to connect to it right away otherwise the process will timeout and die.
Is it for hpc deployment or usage?
Anyway this is awesome...
Thanks for doing that!
On Nov 23, 2018, at 22:35, Vanessa Sochat notifications@github.com wrote:
Adjusted! How does it look now? The one change I didn't do is 1, because it doesn't hurt to have it there. If someone has issue with the extra files they can open a PR. How does it look for 2 and 3?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
That’s a great idea! I am not exactly sure about the use case, @Trophime when you are back in business could you comment - were you just interested in the visualizer? For hpc and singularity not needing write is a huge +1.
Thanks for your work. That's a great step forward. What I have in mind is to use singularity to start one instance of paraview Visualizer after my calculations are done. The idea is to bring a "visualization" feature in the frame of the MSO4SC project.
As a side note, I've played with singularity apache using distribution apache2. It's possible to have an instance running without having to use sudo
. The trick is to make the apache envvars point to alternative directory whe the user has the read/write permissions.. that"s all.
But I don't know about the websockect part...
PS: an alternative for apache is also to use: https://github.com/sylabs/examples/tree/master/http-server/apache2-web-server
hey @jourdain let's move forward and create a visualizer only container for @Trophime. Is there a Docker container existing to start with?
The base docker image to use would be pv-v5.6.0
or pv-osmesa-v5.6.0
depending on your hardware/drivers...
Then you need to run the application that you are targeting. The example below would be for ParaView Visualizer.
/opt/paraview/install/bin/pvpython
${EXTRA_PVPYTHON_ARGS}
/opt/paraview/install/share/paraview-5.6/web/visualizer/server/pvw-visualizer.py
--content /opt/paraview/install/share/paraview-5.6/web/visualizer/www
--port 8080
--data /data
--viewport-max-width 1920
--viewport-max-height 1080
--timeout 30
Where EXTRA_PVPYTHON_ARGS
can be nothing or -dr --mesa-swr
for the osmesa use case.
Any of those args can be tuned but the port used need to remain the same along the way.
cool I'll give it a try!
I'm getting this error even when I try to run bash:
$ docker run -p 0.0.0.0:8080:80 -ti kitware/paraviewweb:pv-osmesa-v5.
6.0 bash
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:402: container init caused \"apparmor: config provided but apparmor not supported\"": unknown.
Am I using the wrong container? (still on my host, no nvidia).
The following command is working for me
docker run -p 0.0.0.0:8080:8080 -ti kitware/paraviewweb:pv-osmesa-v5.6.0 bash
notice 8080 instead of 80
Hmm I don't think the port would make a difference
$ docker run -p 0.0.0.0:8080:8080 -ti kitware/paraviewweb:pv-osmesa-v
5.6.0 bash
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:402: container init caused \"apparmor: config provided but apparmor not supported\"": unknown.
https://docs.docker.com/engine/security/apparmor/#use-aa-status
I think this might be part of Docker but I don't know enough about AppArmor to have much insight. I have
$ docker --version
Docker version 18.09.0, build 4d60db4
and it looks like I do have (some version) of it
$ ls /etc/init.d/apparmor
/etc/init.d/apparmor
Hum, I don't know... Something might be going on. Is there something running on your port 8080?
Nope, I checked! We have tiny sadface empty page paper man:
Maybe I can try building the same Dockerfile? And seeing if my Docker installation produces a container it can use?
sure... That docker image is slow to make as it build ParaView...
Good luck!
Can you point me to the Dockerfile? I again am having trouble finding which one it builds from, sorry for the trouble! Is it this one?
I think there's some issue with my Docker - I did install updates without a restart so let me try rebooting my computer. Which I'm pretty sure I do almost never :P
$ who -b
system boot 2018-11-14 12:49
okay not so terrible! I'll ping with an update after.
@vsoch it works if you use port 8080 not 80! But it's pretty slow...
@jourdain do you know with mesa version is used for paraview superbuild? The one from xenial?
I don't know what xenial is, but the one @vsoch is using it the mesa one for sure hence the performance issue. But replacing pv-osmesa-v5.6.0
by pv-v5.6.0
would fix the speed issue assuming you have the proper drivers and hardware.
This is a larger issue with my system - I don't know what happened, this paraview family was the last that I was working with, and my entire docker is just broken from it. So I can't work on... anything at all. Sorry guys, let's hope this isn't the end of me :*(
xenial is the nickname of ubuntu 16.04 LTS
but to use pv-v5.6.0 we need docker-nvidia installed right?
Yes, but not if you use use singularity with -nv.
Bootstrap: docker
From: kitware/paraviewweb:pv-v5.6.0
%setup
echo "Looking in directory '$SINGULARITY_ROOTFS' for /bin/sh"
if [ ! -x "$SINGULARITY_ROOTFS/bin/sh" ]; then
echo "Hrmm, this container does not have /bin/sh installed..."
exit 1
fi
mkdir -p $SINGULARITY_ROOTFS/data
exit 0
%environment
export LANG=C
PORT=8080
ALLOW_HTTP=true
URL=localhost
export PORT ALLOW_HTTP URL
%startscript
/opt/paraview/install/bin/pvpython \
/opt/paraview/install/share/paraview-5.6/web/visualizer/server/pvw-visualizer.py \
--content /opt/paraview/install/share/paraview-5.6/web/visualizer/www \
--port 8080 \
--data /data \
--viewport-max-width 1920 \
--viewport-max-height 1080 \
--timeout 30 \
> /tmp/pvpython.log 2&1
I've tried with this recipe. The startscript fails to create the 8080 port for some reasons, I don't understand.
However starting the script within the image works really smoothly:
singularity instance start --nv -B data_dir:/data pv.simg wdemo
singularity shell instance://wdemo
Singularity pv.simg:...> /opt/paraview/install/bin/pvpython ...
How to get the start script to work?
Found: a simple nohup
do the trick
Cool! Should we add the finished recipe to the repo for others? (My docker is alive and well again, btw!)
yes sure. I propose a recipe like that:
Bootstrap: docker
From: kitware/paraviewweb:pv-v5.6.0
%help
To start:
singularity instance start --nv -B data_dir:/data pv.simg wdemo
To stop:
singularity instance stop wdemo
To login into the running instance:
singularity shell instance://wdemo
%setup
mkdir -p $SINGULARITY_ROOTFS/data
mkdir -p $SINGULARITY_ROOTFS/usr/local/bin
exit 0
%environment
#export EXTRA_PVPYTHON_ARGS="-dr --mesa-swr"
export LANG=C
PORT=8080
ALLOW_HTTP=true
URL=localhost
export PORT ALLOW_HTTP URL
%post
pwd
cat > /usr/local/bin/start.sh << EOF
#! /bin/bash
/opt/paraview/install/bin/pvpython \
/opt/paraview/install/share/paraview-5.6/web/visualizer/server/pvw-visualizer.py \
--content /opt/paraview/install/share/paraview-5.6/web/visualizer/www \
--port 8080 \
--data /data \
--viewport-max-width 1920 \
--viewport-max-height 1080 \
--timeout 30
EOF
chmod ugo+x /usr/local/bin/start.sh
%startscript
nohup /usr/local/bin/start.sh &
Maybe it needs some cleanup. I guess we have also to provide a solution for people without Nvidia graphic cards... But it will be interesting to check if we got better performances with latest mesa drivers instead of old 17.xx ones but that demand to rebuild every docker involved...
okey doke! How does this look! The "non nvidia" version works for me. It also works without sudo! :confetti_ball:
The link would help, huh? :) https://github.com/singularityhub/paraview-visualizer
@vsoch this is awesome but you are missing $EXTRA_PVPYTHON_ARGS
between those two lines.
That extra arg allow to use mesa-swr as implementation for software rendering that is faster than the default llvm one.
oups, my bad there! How's it look now?
Looks good, thanks!
Bravo :+1:
Great! Do we have any additions or good to close this issue? I'll share to the list so others can use it too - it's much easier to use without needing apache.
For me the issue can be closed
@jourdain I'll let you do the honors, since you opened. Thanks to you both!
A couple of possible cleanup. 1) The directory can be removed as it was needed when I was building the image with ParaView 5.5 since 5.6 was not out yet. This will just save space. 2) In the readme, you need to replace
Mac
byLinux
in the following sentence/data
as this is where the web apps will allow you to load files from.