-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
gzweb8 docker image hangs while creating thumbnails #86
Comments
After leaving my computer for much longer during the build, I found that the script does make progress, but each thumbnail takes about 15 minutes to generate. This is pretty unsustainable, any advice on making it run faster? |
It looks like it built fine just a recently as a few days ago: So gzweb does take a considerable time to build if rendering all model thumbnails. Additionally, a X virtual framebuffer is used to accommodate the missing X server:
|
You can disable thumbnail creation if that's causing problems. They can always be generated later. In this line, instead of running |
Thanks for the tip! The whole container still isn't running for me, but this specific issue is resolved by removing |
It probably failed at the last |
I just tested it localy and the build took:
I think shiping gzweb with the icons is nice for users who might being starting off with gzweb prebuilt in a container and perhaps expecting the interface to be fully functional and rendered. The build time for these tags are only incurred by the Docker Hub build farm and still fit under build time limits, but end users reusing the generated images don't need to spend their own CPU hours rendering or compiling. If you are developing in container with dockerfiles derived from these, perhaps you could just copy out the thumbnail directory into a volume, then just mount that at runtime for the container? That way you can tweak and rebuild the source code quickly, skip the rendering, but still have fully populated UI with testing. |
Thanks for the tips!
@ruffsl: The thumbnails are not required, correct? They are only a
convenience in the UI? If so, I'd say allow it as an optional flag, but if
the cost is hours of build time, make the default be no thumbnails.
|
@Kukanani : thumbnails are not required, and if you don't need to build them then you may change the dockerfile to needs. However, I think as long as the Docker Hub build farm can pre build the gzweb with thumbnails, then there not much reason to not provide it. I suppose we could split the adding of thumbnails into a separate tag, so that there could be an intermediate tag with a minimal gzweb footprint. But nested tags are only really well handled in the official library. Perhaps this could be done once gzweb is released as a debian package so that the tags can be hosted under the official library? |
it may be a while until gzweb is stable and released as deb. If most uses are just pulling from docker hub build farm instead of building it themselves then I think we could leave the thumbnail generation step in there |
Ok, closing for now. |
When omitting the -m flag, the lack of model database causes gazebo to
attempt to download it on first run, which would take a very long time, so
this wasn't really an improvement for me.
|
Would |
Sorry, maybe my use case isn't clear. I want to run gzweb without the Gazebo model database and without thumbnails so that the docker image builds in a reasonable amount of time. Using Either way, the original issue is resolved (technically a non-issue), but building my container still takes a very long time. |
I ticketed an issue on gzweb to disable thumbnail generation on deploy unless specified: |
After switching to using gzweb8 as a result of #84, my docker build hangs while creating its second thumbnail. Please see the output below.
This would seem to be the same problem as #43, but I'm unable to launch the image with an X server to generate the thumbnails, because the image never finishes building in the first place. As far as I can tell, there's not a way to run
docker build
with an X server.Log Summary
The text was updated successfully, but these errors were encountered: