Open iamh2o opened 3 years ago
Wow there is a lot here - thank you for testing so thoroughly! I am hopeful I'll be able to fix these bugs without needing to edit Django source code - I'm going out for a morning adventure and will walk through this carefully when I get back!
okay I've thought about this a bit - I think we need a different design where the server settings and static are kept in the user HOME, possibly a ~/snakeface directory. The reason is because we should be able to just install with pip, and have the same software shared/used by multiple users (and also not rely on needing write where we install it). My one question for you (which led to most of your error and debugging) is what did you already have running on port 5000 that you couldn't use it?
hey @iamh2o ! I've refactored the setup so that settings will now exist in your user home, along with all content that needs to be written (sqlite database, static files, migrations) and I have a PR for you to test here: https://github.com/snakemake/snakeface/pull/22. I think most of your issues above resulted from the fact that the settings weren't being read/honored, and possibly the notebook was disabled, and it led you down a long trail of issues (note that if you get to the point where you are editing Django source code please ask for help first!). I'm not sure why your port 5000 was busy, but you should be able to set a port in the settings or just use --port
to specify a different one (at least I just tested and that worked for me!)
Hi @vsoch -- Yow, what a quick response. Thanks for taking a whack at this so soon, I'll give the PR a shot in the next few days. The port was not the main problem, but just part of the story which was 'some of the settings were not being picked up'. The port I was able to change on the command line, but being able to change the IP address to something other than 127.0.0.1 I could not for the life of me figure out how to do - and that was the bigger problem.
I'm running on a compute node in some server bunker where a lot of folks do computational work, so no one is local w/r/t the box. being able to set anything other than localhost or 127* is the only way to expose apps for us as no one is local. Usually when I play around with apps offering UIs there is an option to set 0.0.0.0, but ideally to set any IP. My solution was to reroute the traffic inbound to localhost and vice-versa, but there must be a django flag that allows that change (I'm a cherrypy person, it's a settings option there). And what was running on port 5000? I'm not sure, but there are a surprising number of ports held on this machine. I'm usually up in the 7-8000s.
I want to be sure it was clear, once I rerouted the port traffic, i was able to log in. Then once logged in (and authenticated with a token and all that jazz), I encountered the erorrs that required hacking the django code (which im not shy about doing, it was certainly not a long term solution, just a way to see how much further I could get. I'll definitely let you know how things go with the fixes, it's incredibly good timing b/c I work with a pack of data crazed Biologists who would be so psyched to be able to run their own workflows.
thanks again--jem
Hi-- I'm REALLY excited for this project. I decided to spend some time exploring the repo, and I'm thrilled with what I'm seeing. I also had to do a lot of hacking outside the docs to get things to run-- which I'd like to offer as a possible guide to help others get going. These are more or all of the steps from install through running snakeface (both running pipes itself and listening to externally executed pipes!). It turned out quite long-- if there is a better format to share this in, I'm happy to relocate- please let me know. I tried to keep my comments in comments, the code executed unmarked and the responses in blocks. There are several bugs/documentation points addressed throughout which felt more natural to leave in the broader step by step since they seemed to be OoO dependent.
If i edit the DOMAIN_HOST or DOMAIN_PORT in the settings.yml, they do not get picked up.
run SF
snakeface
snakeface --port 7612 notebook # !SUCCESS (on the port at least)
I'm not really familiar with django, and could not figure out how to get the IP to not be 127.0.0.1, so i ended up setting up port forwarding with socats
sudo socat TCP4-LISTEN:3434,fork TCP4:127.0.0.1:4343 # i may have the ports on the wrong sides....
This worked, I'd get
development server at http://127.0.0.1:7612/
and socates routed it such that browsers hitting the server now listening on 7621 brokered between the localhost port and the exposed port.Awesome. I logged in
snakeface server logs:
Login, asked to create workflow. Go follow tutorial
from package dir stil
cick create workflow.
! I like the ui a lot !
Choose the toot/snakemake-tutorial dir as my workdir (recall, i am 1 level above it)
set cores to '44'
set conda on
!!! WMS monitor IP:PORT is correct here, but i'm not sure if its from env vars or the yml
enter 'myreport.html' in Report
Hit Run Report
Logs show
And a browser alert box pops up with this error:
Clicking OK does not clear the alert box. Things seem wedged. The stack trace above is not encouraging. Try restarting.
And a browser alert box pops up with:
Clicking OK does not clear the alert box. Things seem wedged. The stack trace above is not encoriaging. Try restarting.
ctrl+C ; snakeface --port 4343 notebk
I hack the url to get back to /
The workflow is in a pending state.
dialog box with same error as above re-appears. seems a js thing as it is causing no logging. but can't clear it
This time just hack the URL don't restart - back to dashboard
Return to the workflow, and click Cancel and confirm.
dialog box reappears, same error msg.
Back to dash, try new workflow. same settings except new report name
Run
Same stack trace logged, same alert box. Hack url back to dashboard.
You might need sit down :-)
I started hacking things out of the code until it worked. What did the trick was
And removed the following
Run again
Load the first WF, cancel it 3x, then click edit, change the name, and re-run
Progress! The stacktrace is gone :-|
The dag appears.... But the alert box is back again with the same message.
Hack url back to dashboard. The workflow has now gone from 'pending' to 'error' state. That is new.
THE WORKFLOW has an error now:
I go edit the settings.yml to turn off auth. This works.
restart, try re-running the first workflow. It runs, but new error:
Suspect the server needs to be running from the snakemake execution dir.... stop snakeface, cd snakemake-tutorial, restart
Try again
Go to first workflow, re-run.
Success! The exhaustive audit trail is there, the dag is there. It's looking really slick
Click on 'View Report'... it loads the interactive DAG plot! slick.
Somehow the alert box error has stopped showing up...
I'm still curious about the working dir thing, restart with workdir set. I'll add verbosity too
cd snakemake-tutorial
snakeface --workdir ~/projects/pelagic/there_be_dragons/SNKFCE/snkfc/snakeface/toot --port 4343 notebook