Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
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
Vahid
@VJalili
e.g.,: https://github.com/VJalili/galaxy/blob/e1d014939fe752cfcf99debc60e5756efe211fbf/lib/galaxy/authnz/managers.py#L141
but when raised in api, the api caller receives a correct error message and code: https://github.com/VJalili/galaxy/blob/e1d014939fe752cfcf99debc60e5756efe211fbf/lib/galaxy/webapps/galaxy/api/cloudauthz.py#L106
Marius van den Beek
@mvdbeek
Sure, that makes sense, that's what the ErrorMiddleware does
but if you call this from somewhere where it doesn't pass through the middleware it won't do that
at least that's my understanding
Vahid
@VJalili
Sounds reasonable. Any suggestion for throwing exceptions behind the middleware? (e.g., in the authnz I linked)
Marius van den Beek
@mvdbeek
huh, that depends on who needs to react to the exception I guess
Vahid
@VJalili
I used to return errors to the caller api/controller. However, I think we're moving from that practice.
its the caller of API that needs to react
Marius van den Beek
@mvdbeek
like this is still going through the HTTP API ?
Vahid
@VJalili
correct
Marius van den Beek
@mvdbeek
then it should actually be caught
Vahid
@VJalili
caught in api/controller?