These are chat archives for getredash/redash

19th
Jan 2016
Takahiro Mitsumori
@TMit
Jan 19 2016 07:55
This message was deleted
I had few errors on "Apply migrations" step at "Setting up development environment (using Vagrant)" process.
I tried at c1da257.
the first one is
Traceback (most recent call last):
  File "migrations/0003_update_data_source_config.py", line 72, in <module>
    for data_source in DataSource.all():
TypeError: all() takes at least 2 arguments (1 given)
Arik Fraimovich
@arikfr
Jan 19 2016 07:56
[Arik Fraimovich, re:dash] @tmit: yes... someone reported this earlier on a GitHub issue. Unfortunately recent code changes aren't compatible with old migrations. We should create a new vagrant box. For now, I suggest just dropping the tables, and recreating them again with the CLI. (check manage.py database --help)
Takahiro Mitsumori
@TMit
Jan 19 2016 08:32
@arikfr I did this command to fixed it. Thanks.
./bin/run ./manage.py database 'create_tables'
Arik Fraimovich
@arikfr
Jan 19 2016 08:38
[Arik Fraimovich, re:dash] Great. Glad it's working.
xiandelife
@xiandelife
Jan 19 2016 10:35
@arikfr Thanks for the help. I have fixed the problem. It is the same as the migration error in the vagrant box. I have tried the new permission system and I find that when I add new data source to a group, it may cause repeated data sources list options on the query page.
Screen Shot 2016-01-19 at 11.37.13.jpg
Arik Fraimovich
@arikfr
Jan 19 2016 10:53
[Arik Fraimovich, re:dash] @xiandelife interesting. I will check it out.
Arik Fraimovich
@arikfr
Jan 19 2016 11:52
This message was deleted
This message was deleted
Dan Berglund
@cheif
Jan 19 2016 13:47
Hi there! Anyone having experience with running re:dash on Amazon ECS?
I've got everything up and running, but requests seem to take a lot of time (resulting in timeouts), however, when I run it in docker with the same parameters it works just fine.
2016-01-19 13:47:52 [13] [CRITICAL] WORKER TIMEOUT (pid:337)
2016-01-19 13:47:52 [13] [CRITICAL] WORKER TIMEOUT (pid:338)
2016-01-19 13:47:52 [348] [INFO] Booting worker with pid: 348
2016-01-19 13:47:52 [13] [CRITICAL] WORKER TIMEOUT (pid:338)
2016-01-19 13:47:52 [349] [INFO] Booting worker with pid: 349
2016-01-19 13:47:52 [350] [INFO] Booting worker with pid: 350
[2016-01-19 13:47:52,490][PID:348][WARNING][redash.query_runner] MQL query runner enabled but not supported, not registering. Either disable or install missing dependencies.
[2016-01-19 13:47:52,495][PID:350][WARNING][redash.query_runner] MQL query runner enabled but not supported, not registering. Either disable or install missing dependencies.
[2016-01-19 13:47:52,525][PID:349][WARNING][redash.query_runner] MQL query runner enabled but not supported, not registering. Either disable or install missing dependencies.
[2016-01-19 13:47:52,556][PID:348][WARNING][redash.query_runner] Oracle query runner enabled but not supported, not registering. Either disable or install missing dependencies.
[2016-01-19 13:47:52,602][PID:350][WARNING][redash.query_runner] Oracle query runner enabled but not supported, not registering. Either disable or install missing dependencies.
[2016-01-19 13:47:52,618][PID:349][WARNING][redash.query_runner] Oracle query runner enabled but not supported, not registering. Either disable or install missing dependencies.
2016-01-19 13:48:32 [13] [CRITICAL] WORKER TIMEOUT (pid:345)
2016-01-19 13:48:32 [13] [CRITICAL] WORKER TIMEOUT (pid:345)
Example from stdout ^
My feeling is that there's some resources missing or similar, but I've boosted both ram and CPU pretty high
Arik Fraimovich
@arikfr
Jan 19 2016 13:49
I remember seeing this error. But unfortunately I don't remember what was the solution :disappointed:
It shouldn't be resources, as the system isn't that resource hungry
maybe security groups issues w/ the db or redis?
Dan Berglund
@cheif
Jan 19 2016 13:50
Hmm, I'm running redis in the same container, and that seems to work good when running outside of ECS
Same with postgres
Requests finishing seem to take 40-50 sec
Arik Fraimovich
@arikfr
Jan 19 2016 13:51
I would recommend not doing that. At least for Postgres, as it's more resource hungry and you want it to persist when upgrading. Use t2.micro/nano RDS instance instead
Dan Berglund
@cheif
Jan 19 2016 13:52
Ooh, bad wording from me. Redis is running in the same container, but postgres is it's own instance
But it seems to work from another container outside of ECS
Arik Fraimovich
@arikfr
Jan 19 2016 13:53
ok, cool then. how much resources did you give it?
Dan Berglund
@cheif
Jan 19 2016 13:53
Something like 800MB of memory and 10% of the CPU
Arik Fraimovich
@arikfr
Jan 19 2016 13:54
hmm.. maybe try giving more CPU. as for memory you can do with less, but it depends on # of workers you need / size of queries
Dan Berglund
@cheif
Jan 19 2016 13:54
On a C4-large instance
Dan Berglund
@cheif
Jan 19 2016 14:02
Tried boosting it to 50% CPU, but the same symptoms
And docker stats says it's not using an CPU at all, and about 40% mem
Dan Berglund
@cheif
Jan 19 2016 14:38
Aah, found it out!
It seems like amazons load-balance (ELB) doesn't really like gunicorn, with regards to holding sockets open ect.
The easy way was to just tell gunicorn to use gevent-workers
Then it seems to work just fine :)
Arik Fraimovich
@arikfr
Jan 19 2016 16:14
@cheif oh , right! now I remember what I did: I put an nginx proxy between gunicorn and ELB. nice catch.
Arik Fraimovich
@arikfr
Jan 19 2016 16:27
@xiandelife fix for the issue you found (with duplicate datasources) will be part of the next release
Parker Lawrence
@parkeristyping
Jan 19 2016 21:25
I have re:dash installed on an ec2 instance, for which I followed the instructions to setup ssl. I'm unable to run $ sudo supervisorctl commands (e.g. $ sudo supervisorctl stop redash_celery) after SSHing into the machine. I get http://localhost:9001 refused connection.
Any ideas what is wrong? Do I perhaps need to update this line in my supervisord.conf? If so, to what?
[inet_http_server]
port = 127.0.0.1:9001
Arik Fraimovich
@arikfr
Jan 19 2016 21:33
@ parkeristyping: maybe try the brute force approach and restart supervisord -- /etc/init.d/redash_supervisord restart
Parker Lawrence
@parkeristyping
Jan 19 2016 21:37
$ /etc/init.d/redash_supervisord restart
start-stop-daemon: unable to set gid to 65534 (Operation not permitted)
   ...fail!
(Sorry for just copy/pasting my errors directly - just not familiar at all with supervisord. No expectation that you will step through this with me, just as FYI. In any case thanks for the suggestion!)
Arik Fraimovich
@arikfr
Jan 19 2016 21:39
Run it with sudo. I forget that above.
Parker Lawrence
@parkeristyping
Jan 19 2016 21:40
:+1:
Seems to have done the trick - thanks!
Arik Fraimovich
@arikfr
Jan 19 2016 21:42
Great :-)