Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Carrie
@cganote
Hey folks, I have one tool I'm testing which always seems to error out during the metadata step. This is running inside a new galaxy docker, 18.05 I think:
https://gist.github.com/carrieganote/a2f0dc8c42dc368cad1fb0239d6dd79c
How can I go about debugging this? It's a little weird that the sqlalchemy step is the one that is failing. The tool is a little strange in that it produces a tar.gz file, but this hasn't been a problem in our traditional galaxy installs.
Marius van den Beek
@mvdbeek
I'd start by checking that this tool passes tests in planemo
If it does, there might be something funky in the stdout or stderr that postgresql in the container doesn't tolerate
Carrie
@cganote
I'll see about planemo, and change the tool to >> logfile 2>&1 to see if that helps
jhl667
@jhl667
@mvdbeek Ok, hopefully I can stop bothering you soon. Above error message simply says that when I am attempting to install from beta toolshed, the tool_conf selection is empty, or None. The new question is why the heck is this not being populated? The files are there, they are defined in the galaxy config file, permissions are correct, weird!
Marius van den Beek
@mvdbeek
yeah, that's a known bug unfortunately
I really thought I had send a message this morning, but sometimes the gitter app swallows a message :(
sorry
jhl667
@jhl667
it's ok, will this affect non-beta toolshed installations as well?
Marius van den Beek
@mvdbeek
no
jhl667
@jhl667
in our 17.09 instance that box gets populated, so I was hoping it was connected to the failed toolshed installations in the 18.05 instance
Marius van den Beek
@mvdbeek
no
just gotta find some time to dig into this
jhl667
@jhl667
well, my main goal in figuring out this issue with toolshed installations was to provide a dev environment on our cluster so we could start pushing our work to the toolshed. I've spent too much time on this though, so I'll try to revert back to a previous version, appreciate the help
jhl667
@jhl667
@mvdbeek Ok, so I had completely given up, then went back and re-scoured for the umpteenth time the galaxydev mailing list. I found the thread between you and PB talking about not being able to find hg. I must've ignored this the first time around since it is utilizing the virtualenv method, whereas I have switched to using conda for framework deps. So, all I did was add the path to the galaxy_1805 conda env directly to the galaxyuser PATH variable and it works fine. Wow, I'm broken, time for a drink.
Marius van den Beek
@mvdbeek
well, glad it works, but that doesn't really fit the issues we had been discussing. Also that approach will probably have other issues
jhl667
@jhl667
well the issue I originally talked about was that I tried to install via toolshed and it immediately went to failed status
then we started looking at cross-origin issues
Marius van den Beek
@mvdbeek
huh ?
I thought it'd just sit there forever
well OK, that sort of makes sense then, but putting conda on PATH is probably still not a good idea
jhl667
@jhl667
no, the gui showed immediate failure, and the log would just spin off prepare_for_install requests every 3 sec
Marius van den Beek
@mvdbeek
yeah, jumped to conclusions there
jhl667
@jhl667
yea, I agree with you on PATH not being a great idea, what would be your suggestion?
Marius van den Beek
@mvdbeek
put galaxy's virtualenv path on the PATH
jhl667
@jhl667
I don't use a virtualenv
I use conda to manage all of that
Marius van den Beek
@mvdbeek
that is also not a good idea
jhl667
@jhl667
it works quite well for me since otherwise I need to install two virtualenv's
Marius van den Beek
@mvdbeek
right, except for the mercurial issue that would've been avoided, plus X
I mean OK, if it works it works
jhl667
@jhl667
I only tried it after reading about it in the docs, but if you suggest it's not a good idea, I can go back to double virtualenv
Marius van den Beek
@mvdbeek
I don't know, if it's just for dev it's fine
jhl667
@jhl667
I guess I'm trying to figure out some of the reasons you're wary of conda for this purpose
Marius van den Beek
@mvdbeek
but you're not getting the wheels we're testing with, and I don't think that the exact dependency versions match either (case in point mercurial wasn't installed)
jhl667
@jhl667
ahh, ok, well that's a good reason
:-)
selten
@selten
I'm curious, how does https://usegalaxy.org/ handle inode usage? Or is that no issue?
Ieva
@Le_ieva__twitter
Is Galaxy slow today or is there something wrong on my end? :/
Björn Grüning
@bgruening
usegalaxy.org or another server?
pvanheus
@pvanheus
@mvdbeek I'm trying to use the https://github.com/ARTbio/GalaxyKickStart with the standard galaxy.yml and inventory as per https://gist.github.com/pvanheus/24615ececac112937b706d87dfb5b846 - but it seems to not configure supervisor - the supervisor stuff is meant to come from galaxyprojectdotorg.galaxy-os right?
pvanheus
@pvanheus
ah no - supervisor is from galaxyprojectdotorg.galaxy-extras - seems the default galaxy.yml doesn't include that.
Marius van den Beek
@mvdbeek
Right, supervisor setup is in ansible-galaxy-extras
Vahid
@VJalili
@jmchilton raising exceptions such as RequestParameterMissingException in places other than api/controller causes 500 error. Any thoughts?
Marius van den Beek
@mvdbeek
do you have an example ?
I think MessageExceptions are caught in the ErrorMiddleware, so if they don't leave galaxy that makes sense
Marius van den Beek
@mvdbeek
Sure, that makes sense, that's what the ErrorMiddleware does