Closed smirs closed 3 years ago
smirs
commented
4 years ago Solution: Isntalling node.js and vpm.
Action item: in the installation guide page, it needs to be added to install these packages. Specially because it doesn't directly get displayed in logs when trying to follow the current version of documentation here: https://superset.incubator.apache.org/installation.html#start-with-docker
cocodrino
commented
4 years ago @smirs Hi, sorry how did you install node and vpm?..I'm having the same problem, I notice that there are several containers
in my case I'm getting several logs indicating an issue with some npm dependencies
chandresh-pancholi
commented
4 years ago Facing same issue with docker-compose up
mistercrunch
commented
4 years ago @craig-rueda , who has most context on our docker / docker-compose
craig-rueda
commented
4 years ago Could be related to the node modules volume? Try re-pulling master and re-up.
foodata
commented
4 years ago same problem +1
retbrown
commented
4 years ago Try leaving it to run for about 5 - 10 minutes. I had the same issue but leaving it webpack started printing messages and eventually I was able to load it when webpack finished but took about 5 minutes locally
craig-rueda
commented
4 years ago Thanks for reaching out, guys. We're aware of this lagginess when it comes to the node container and are actively looking at it. Thanks again, and stay tuned for updates!
-Craig
On Thu, Jul 16, 2020 at 8:03 AM Robert Brown notifications@github.com wrote:
Try leaving it to run for about 5 - 10 minutes. I had the same issue but leaving it webpack started printing messages and eventually I was able to load it when webpack finished but took about 5 minutes locally
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/apache/incubator-superset/issues/9880#issuecomment-659471654, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATZTWYWTHUEZJRPHMEVG5DR34JD7ANCNFSM4NHHRZUA .
PhucNgo1711
commented
4 years ago I'm having this issue as well. This is my log. I also nuked the volumes, reran compose up, and pulled the lastest from master.
EDIT: Also got this issue when I followed this But this worked.
superset_app | INFO:werkzeug:172.18.0.1 - - [12/Aug/2020 22:09:09] "GET / HTTP/1.1" 302 -
superset_app | 172.18.0.1 - - [12/Aug/2020 22:09:09] "GET /superset/welcome HTTP/1.1" 200 -
superset_app | INFO:werkzeug:172.18.0.1 - - [12/Aug/2020 22:09:09] "GET /superset/welcome HTTP/1.1" 200 -
superset_app | 172.18.0.1 - - [12/Aug/2020 22:09:09] "GET /static/assets/images/loading.gif HTTP/1.1" 404 -
superset_app | INFO:werkzeug:172.18.0.1 - - [12/Aug/2020 22:09:09] "GET /static/assets/images/loading.gif HTTP/1.1" 404 -
superset_app | 127.0.0.1 - - [12/Aug/2020 22:09:20] "GET /health HTTP/1.1" 200 -
superset_app | INFO:werkzeug:127.0.0.1 - - [12/Aug/2020 22:09:20] "GET /health HTTP/1.1" 200 -
siarcarse
commented
4 years ago Same here!. The problem was the amount of memory allocated to Docker. I increased ram and cpu and solved.
zhenbo
commented
4 years ago I have experienced similar issue when trying to setup superset for the first time. Hopefully this could be resolved so we can lower the barrier for people who is excited about superset's potential
jinhuang11
commented
4 years ago I also experienced the same issue when trying to deploy on my MacBook Pro. Tried a few things, no luck yet. Will keep trying. Any suggetions?
thanwin
commented
4 years ago same on fresh install ubuntu 18.04 LTS vm. install via github.
INFO:werkzeug:192.168.122.1 - - [29/Aug/2020 11:27:27] "GET /static/assets/images/favicon.png HTTP/1.1" 404 -
INFO:werkzeug:192.168.122.1 - - [29/Aug/2020 11:27:40] "POST /login/ HTTP/1.1" 302 -
INFO:werkzeug:192.168.122.1 - - [29/Aug/2020 11:27:40] "GET / HTTP/1.1" 302 -
INFO:werkzeug:192.168.122.1 - - [29/Aug/2020 11:27:41] "GET /superset/welcome HTTP/1.1" 200 -
INFO:werkzeug:192.168.122.1 - - [29/Aug/2020 11:27:41] "GET /static/assets/images/loading.gif HTTP/1.1" 404 -
INFO:werkzeug:192.168.122.1 - - [29/Aug/2020 11:27:52] "GET /superset/welcome HTTP/1.1" 200 -
INFO:werkzeug:192.168.122.1 - - [29/Aug/2020 11:27:52] "GET /static/assets/images/loading.gif HTTP/1.1" 404 -
INFO:werkzeug:192.168.122.1 - - [29/Aug/2020 11:28:54] "GET /superset/welcome HTTP/1.1" 200 -
INFO:werkzeug:192.168.122.1 - - [29/Aug/2020 11:28:54] "GET /static/assets/images/loading.gif HTTP/1.1" 404 -
INFO:werkzeug:192.168.122.1 - - [29/Aug/2020 11:33:57] "GET /superset HTTP/1.1" 404 -
INFO:werkzeug:192.168.122.1 - - [29/Aug/2020 11:33:57] "GET /favicon.ico HTTP/1.1" 404 -
INFO:werkzeug:192.168.122.1 - - [29/Aug/2020 11:34:05] "GET / HTTP/1.1" 302 -
INFO:werkzeug:192.168.122.1 - - [29/Aug/2020 11:34:05] "GET /superset/welcome HTTP/1.1" 200 -
INFO:werkzeug:192.168.122.1 - - [29/Aug/2020 11:34:05] "GET /static/assets/images/loading.gif HTTP/1.1" 404 -
@thanwin - looks to me like you need to bump your Docker memory limits in order to allow for the npm build to run correctly. I see that all of the Flask-served requests are returning 200, whereas the static assets aren't built.
opzetto
commented
3 years ago I have experienced similar issue when trying to setup superset for the first time. Hopefully this could be resolved so we can lower the barrier for people who is excited about superset's potential
I am facing the same issue, may I ask how did you solve the problem?
imnot70
commented
3 years ago same problem +1 again
licx
commented
3 years ago same problem
licx
commented
3 years ago I solved it by:
1) Bumping Docker memory to 16GB (not 100% sure if helped since I already had 8gb there)
2) Running docker-compose up and wait 10 minutes until Webpack kicked off the build
jinhuang11
commented
3 years ago Worked for me now after reinstalling Docker, increasing Docker memory to 16GB, running "docker-compose up" and waiting for about 15 minutes after superset-frontend node_module build complete. Thanks for sharing the tips @guys.
The authentication is ready earlier in the process, the frontend along with all the super rich data/dashboard taking time to process, maybe a placeholder message in UI and server log will help
zhenbo
commented
3 years ago Thanks for the updates. I will bump up docker to 16GB and wait.
ghost
commented
3 years ago Wait around 5 minutes until it stop printing on the screen, then you're all set. But it may use large amount of ram so you might increase docker ram to 16GB like others said.
kaovilai
commented
3 years ago Facing similar issue on Ubuntu 20.04 LTS via WSL 2 on Docker for Windows with WSL 2 Integration
kaovilai
commented
3 years ago Facing similar issue on Ubuntu 20.04 LTS via WSL 2 on Docker for Windows with WSL 2 Integration
and.... fixed itself after a few hours.. of idling
mistercrunch
commented
3 years ago We've noticed in the past that building the javascript bundles is pretty io intensive and that docker in some context doesn't do io as well. OSx used to be pretty bad and things could degrade while in container-in-container mode. Unclear how Docker on Windows does with this. Unclear if that's the part of the issue or not, but something to keep in mind.
andrewhaighcell
commented
3 years ago I experienced the same kind of behaviour, restarted my docker machine vbox image with 4Gb memory and 2 cpus and left it for an hour or so. The static assets now appear to be present.
siben168
commented
3 years ago I've got exactly same blank page. From my case, i've also seen following errors from stage superset_init:
superset_init | urllib.error.URLError: <urlopen error [Errno 99] Cannot assign requested address>
siben168
commented
3 years ago Facing similar issue on Ubuntu 20.04 LTS via WSL 2 on Docker for Windows with WSL 2 Integration
and.... fixed itself after a few hours.. of idling
That is amazing, i followed you and it worked after one hour waiting for some web packages installations. I've also used WSL2.
rafaelugolini
commented
3 years ago I had the same issue, took around 7m for webpack to finish
superset_node | <s> [webpack.Progress] 100%
superset_node | No type errors found
superset_node | Version: typescript 3.8.3
superset_node | Time: 412075ms
superset_node |
superset_node | 8278 modulesMy guess is that given that the build operation is super io-heavy and that virtualization, depending the platform you're on (say docker on windows, or docker-in-docker, or whatever) can make certain io operations sluggish, and really slow down the build process. Looks like the node_modules/ folder contains a quarter million files (!)
$ find superset-frontend/node_modules/ | wc -l
240901It would be good to have official docker images from the project that don't require you to compile. Any newcomer who wants to try superset has to do all this compilation process to run the project.
For anyone who wants to give it a try, here is a link to unofficial docker images:
jvanulden
commented
3 years ago It would be good to have official docker images from the project that don't require you to compile. Any newcomer who wants to try superset has to do all this compilation process to run the project.
For anyone who wants to give it a try, here is a link to unofficial docker images:
I concur. This should be table stakes IMO.
korridor
commented
3 years ago I think I have the same problem I also get ENOENT: no such file or directory, open '/app/superset-frontend/node_modules/.staging/... errors during the npm build.
I am using Docker Desktop 2.5.0.1 on Mac. I gave Docker 16GB RAM, 4GB Swap, 6 CPUs and more then enough disk space so I hope missing resources is not the problem.
This is the logfile: superset.log
nytai
commented
3 years ago We have switched over to using prebuilt images hosted on docker hub, see https://github.com/apache/incubator-superset/pull/11707
@korridor can you try pulling the latest master and running docker-compose again?
korridor
commented
3 years ago @nytai Thanks now it's working! I was using the master instead of the master-dev tag for some reason.
Lynnhan95
commented
3 years ago I have run into this issue, and it worked after installing the latest NPM and node.js.
heyhpython
commented
3 years ago superset_node container memory up to 4G solve this in my case
belal-mazlom
commented
3 years ago I found myself forced to enter to superset-frontend and run npm run build
To make assets available
olmar
commented
3 years ago After increasing Docker memory limits I recreated superset-node service via:
docker-compose kill superset-node
docker-compose rm superset-node
docker-compose up -d superset-nodesuperset-node was able to build assets in this case.
wahyd4
commented
3 years ago Got the same issue here when I following the official installation guide https://superset.apache.org/docs/installation/installing-superset-using-docker-compose.
It's pretty disappointing that having this issue in release/stable versions (I've tried both 1.0.0 and 1.0.1).
mrdavidlaing
commented
3 years ago I found running docker stats in a separate terminal window helpful for monitoring whether the superset_node image was "busy"
nytai
commented
3 years ago @wahyd4 docker-compose is a dev environment set up. If you'd like to run an official version you can use the pypi distribution, ie pip install apache-superset or you can use one of the official release docker images, https://hub.docker.com/layers/apache/superset/1.0.1/images/sha256-8accc0a4bc0af3293e64c6dfe78bec16de8525ebdc5d649eca21d77fa3e73da8?context=explore
This of course means you will have to provide your own metadata database, redis instance, and you will have to configure workers properly in another container. Up to you which set "issues" you're more comfortable dealing with
wahyd4
commented
3 years ago @nytai Thanks for the clarification and explanation. It does make sense to me. But I suspect many people didn't expect that we have to compile resources when running app via docker-compose. It would be great if we can have some more detailed documentation about running production ready superset app via docker, docker-compose or Kubernetes.
I do acknowledge there is some doc from official website https://superset.apache.org/docs/installation/installing-superset-from-scratch about install superset via helm but it doesn't provide any introduction about helm variables and how to config them.
nytai
commented
3 years ago The published docker containers already include the compiled resources. docker-compose volume mounts the repo and sets things up for development purposes, hence why the compilation step is necessary. We could add a version of docker-compose without volume mounts for quickly testing the app out, however that should ideally not be used in prod. The helm chart is also a great way to set up the app quickly for testing but it’s also not ideal for large scale prod deployments as it relies on containerized instances of redis and Postgres. It also expects knowledge of helm charts (most config usually happens in values.yaml)
As far as prod deployments, there are so many ways to run a flask app, celery app, celery beat app, provide a database, redis instance, etc. that documenting each would be a huge task. We could point to other resources for deploying flask/celery apps though
wahyd4
commented
3 years ago @nytai I agree with you that docker-compose shouldn't be used for production ideally, and it provides a super fast way for user to test superset by 1 command.
But I wouldn't agree with your thoughts on Helm, we don't have to using the embedded Database and Redis to run the application, and I wouldn't think people do that way to setup production clusters. That's why we provide option to use external database and redis instances in Helm, isn't it? If a user don't know too much about helm then use the quick start command, otherwise check the README to customize. Definitely there are lots of ways to run superset, but given we have provided helm as an option, so hope we can provide some more information about it which is similar to the archived superset helm chart https://github.com/helm/charts/tree/master/stable/superset
Anyway, thanks for the explanation, I have tried the apache/superset docker image locally, it works great.
nytai
commented
3 years ago @wahyd4 Actually, that deperacted helm chart got moved into the superset repo, so all that documentation still applies. If you're up for it, you could open a PR to include that readme in thehelm/superset directory. Some changes will be required to reflect the new paths, but it should be fairly straight forward.
Additionally, you've inspired me to cook up a docker-compose file explicitly for testing out superset and not developing, https://github.com/apache/superset/pull/13143
mtv2102
commented
2 years ago Thanks for the updates. I will bump up docker to 16GB and wait.
Did this solved your issue? Because I am also facing this currently..
Drun1baby
commented
6 months ago same problem +1 again
And I can not see the way to solve this issue in version 3.0.3
I am on ubuntu. I am following the instructions to install Superset via docker via this link: https://superset.incubator.apache.org/installation.html#start-with-docker
Expected results
I expect after these steps if I open http://localhost:8088, I see Superset UI
Actual results
I see a blank page at http://localhost:8088
Screenshots
How to reproduce the bug
Environment
(please complete the following information):
Checklist
Make sure these boxes are checked before submitting your issue - thank you!
Additional context
Here is the full log: