-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Fix Galaxy ignoring job object_store_id for quota check #19854
Conversation
Hah, seems that I came up with the same solution as: #19589 .. minus the test :) |
42de948
to
ec7a075
Compare
0998632
to
3ade103
Compare
36496c0
to
b516c7e
Compare
The test errors sure look related |
seems that we ignored the job's object_store_id and only used an (undocumented?) object_store_id param of job destinations.
the destination param should have been considered [here (in both cases)](https://github.com/galaxyproject/galaxy/blob/7ff91d8df65b0f55875167fbbcbb6dedaef99ee0/lib/galaxy/jobs/__init__.py#L1648) already.
b516c7e
to
3276d1c
Compare
makes testing also a lot easier I think
3276d1c
to
d6990b0
Compare
Thank you, that's much needed! |
This PR was merged without a "kind/" label, please correct. |
Should this be backported? I would suggest 24.1. |
Really uncomfortable with that, maybe carry that patch if you want to test ? |
Sure. I'm already doing this. |
On my instance I noticed that (irrespective of
object_store_always_respect_user_selection
) quotas for object stores are ignored.To me it seems that we ignored the job's object_store_id and only used an (undocumented?) object_store_id param
of job destinations. In the 2nd commit I completely remove destination parameter, because I think that the destination param should have been considered here (in both cases) already.
Opening against dev for better testing. We probably want to backport this?
xref #19589
How to test the changes?
(Select all options that apply)
License