-
Notifications
You must be signed in to change notification settings - Fork 13.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issues related to dev branch .yml and some documentation #19925
Comments
Small update: I have come across a workaround in ISSUE 16432 that addressed Q2 (which I have stricken.) The workaround was the first half of nytai's comment to comment out the superset-websocket service part of the docker-compose.yml file. This allowed me to then successfully run Questions 1 and 3-6 have yet to be addressed. EDIT: A bit more information, upon searching for the phrase in Q3.3 (FATAL: database files are incompatible with server superset_db), the only 2 relevant results I have come across are 1. over here and 2. over here. I would like to say that the only postgres database I have created and exposed specifically for superset was made just 2 days ago after a fresh install of postgresql version 14.2-1. Version 10.0-1 was released on 6-Nov-2017. |
Another quick update (before I call it a night): following the paths within the docker-compose.yml file lead me to a readme.md under This also somewhat provides context for Q3: maybe the reason I am seeing a lot of errors is because I'm missing some kind of environmental setup that permits development, though I can't really be sure of this. Questions 1, 3 and 5-6 have yet to be addressed. |
Many updates:
Additionally, I am unsure who to thank for this but it would seem that turning It would appear the crux of my problem has been solved by the age old solution of RTFMing with a fine-toothed comb, though I guess the teeth of my comb could be a little larger if the documentation was ever-so-slightly more encompassing. Only Q3 and Q5 remain. |
@RaSi96 superset_db DETAIL: The data directory was initialized by PostgreSQL version 10, which is not compatible with this version 14.2 Seemed clear that the my previous install db data dir was being pointed to somewhere.
Listing the volumes in docker
Solution was to remove the old volume for
|
Hi @jbat, thanks for responding! Your solution seems to make sense, in response I decided to revisit Superset and give it a whirl again today, reinstalling from scratch using For reference, no part of my system has changed except for the versions of all my software. This time I tried with Arch 6.1.11, Postgres 15.1, Docker 1:23.0.1, Docker-Compose 2.16.0, Python 3.10.9. EDIT: I missed a step when setting up my database connection but even with PSQL accessible, I still don't face the loop issue. EDIT: Much later, I still don't seem to be facing this issue when using Superset nowadays, so verifying whether it's the pointer to the database or not is something I can't do, heh. Since the meat of this issue has been addressed, I'll close it. |
Hello team,
This is my first issue ever here on GitHub, so please let me know if anything is amiss. I am a bit apologetic that my problems have something to do with this fantastic software, but my questions have been mounting over the last few days.
The source of my issue here is that superset, as of the time of my writing, still for some reason doesn't support simple scatterplots.(See this comment.)Since bubble charts aren't a 1:1 replacement for a scatter for for me (they require 3 mandated variables?) as recommended here, I decided to use a line plot and arrived at PULL 17917. However, starting a non-dev superset instance using(See this comment.)docker-compose -f docker-compose-non-dev.yml up
and attempting to use a line chart unfortunately still asks me for a temporal dimension - is this because I am running the non-dev branch or is it something else?I then assumed that the dev branch would be a bit further ahead, so I updated my superset folder using(See this comment.)git pull origin master
anddocker-compose -f docker-compose-non-dev.yml pull
(both of which succeeded), but usingdocker-compose -f docker-compose.yml pull
succeeds with everything except superset-websocket: WARNING: Some service image(s) must be built from source by running:docker compose build superset-websocket
. pull access denied for superset-websocket, repository does not exist or may require 'docker login': denied. Runningdocker compose build superset-websocket
succeeds, but retryingdocker-compose -f docker-compose.yml pull
returns the same error.[Edited after my third comment] Attempting to run the dev branch using
docker-compose -f docker-compose.yml up
struck me with ISSUE 7800. I followed these suggestions from there:But nothing worked. Each and every time superset services kept going into an endless error loop where one service would exit with error[1] and cause all the other images to fail with error[1], constantly printing out their error messages to my terminal until it froze:
do the dev and non-dev branches differentiate between development of the superset software or development of data visualisations?(See this comment.)when I use
openssl rand -base64 42
I get numbers and symbols; using this as my secret key doesn't work due to the symbols. Am I supposed to include them?another warning that keeps popping up is(See this comment.)the $CYPRESS_CONFIG variable is not set. Defaulting to a blank string.
when usingdocker-compose -f docker-compose.yml up
. Is this something I should be setting? I have searched in docker-compose.yml as well as superset_config.py, but haven't found anything that's the$CYPRESS_CONFIG
.Additionally if I may, I feel like this is something that should really be addressed in the documentation for superset: running superset in a docker container means using
localhost:5432
to connect to a postgres database won't work even if psql is listening on the applicable port becauselocalhost
, to the docker container, means it only sees itself, not the actual host machine. Instead, pg_hba.conf should be configured to listen on the container's IP and superset should be given the host machine's ipv4/ipv6:5432 to successfully connect (see this article which is also of great help.) These little details took me a rather surprising amount of time to digest :)Once again I apologise for bringing what seems to be an exhaustive list of problems with superset, but any help with these issues would be tremendously appreciated. I'm quite certain it's something very elementary that I'm overlooking, because updating my superset copy and using the non-dev branch is smooth as butter; only the dev branch causes an issue. I came across this project a week ago and have since thoroughly enjoyed using it whenever I can, and I'm very excited to see this project succeed.
EDIT: I thoroughly forgot to add in system information.
Please let me know if any more information is required.
In the interim it appears I'm resigned to the superset non-dev branch for most of my work.(See this comment.)The text was updated successfully, but these errors were encountered: