Skip to content
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

Can't mount TESP docker image #93

Open
micoleaoo opened this issue Feb 4, 2025 · 14 comments
Open

Can't mount TESP docker image #93

micoleaoo opened this issue Feb 4, 2025 · 14 comments

Comments

@micoleaoo
Copy link

micoleaoo commented Feb 4, 2025

default_docker_image in group_vars/galaxyservers.yml keeps defaulting to hub.cerit.io/josef_handl/tesp-test-image even though we defined docker_enabled: true

Image

tes.py
def get_docker_image(self, job_wrapper: JobWrapper):

@martenson
Copy link
Member

you set the docker image to that value on this line: https://github.com/CESNET/usegalaxy/pull/72/files#diff-9bc5553c99bc94777d9f395d0b59b4ddbbd90a213d7dae9eb86ece159e9602bdR71

I am not sure what you're expecting or going for. Could you elaborate please?

@martindemko
Copy link
Collaborator

Exactly. I think you need to remove that line and see if it works. docker_enabled: true is a good start. But I'm not sure if that default_docker_image parameter on the runner level is doing the same as docker_default_container_id on the environment level.

@micoleaoo
Copy link
Author

@martenson We're trying to mount remote image instead of default. This line should mount remote image if it's present

@martindemko I've tried both removing and leaving that parameter empty before and unfortunately it crashed both times.

@martindemko
Copy link
Collaborator

martindemko commented Feb 6, 2025

I don't remember exactly, but that is the image where the tool is supposed to work, correct? In that case, you need that image to be found using Galaxy code (that part is done and everybody uses it) and not to use some hardcoded image. AFAIK that code used @josefhandl when starting with this to simplify the implementation. I think you should remove the line and also the code handling that variable. As I mentioned before, Galaxy has the machinery to handle containers, and there already is the parameter docker_default_container_id, which can be used if nothing better is found. Read https://docs.galaxyproject.org/en/latest/admin/special_topics/mulled_containers.html

@martenson
Copy link
Member

What tool are you running?

@micoleaoo
Copy link
Author

I thought we're already using galaxy machinery - def _find_container is from galaxy
Shouldn't default_docker_image in group_vars/galaxyservers.yml get overwritten if we have remote image present?

I'm running fastqc.

@martenson
Copy link
Member

martenson commented Feb 7, 2025

correct, if standard fastqc from IUC is run on qa2 it should resolve to use the biocontainer

The screenshot above does not say what image was actually used it just tells you what the default values are. You need to inspect the logs to see what Galaxy resolver was looking for and what it found.

@martenson
Copy link
Member

Also looking in the admin interface of QA2 it seems you've installed fastqc with conda dependencies, which means container is not going to be used afaik

@micoleaoo
Copy link
Author

It's showing in the log as well, however, you're right, I'll try to run it without conda

@micoleaoo
Copy link
Author

Is there any major difference when I install fastqc through Galaxy UI (without dependencies ofc) instead of terminal??
Pulsar logs still show hub.cerit.io/josef_handl/tesp-test-image as mounted image.
Can you point me to how to check Galaxy resolver? Should it show in Galaxy logs? Can't find anything there

@martenson
Copy link
Member

martenson commented Feb 13, 2025

@micoleaoo there shouldn't be a functional difference between using API and using UI to install a tool

Given you did not install conda deps for the tool and the destination has docker enabled the following resolvers for containers are active (in order): https://github.com/CESNET/usegalaxy/blob/main/group_vars/galaxyservers.yml#L146

@micoleaoo
Copy link
Author

Yes, that finally worked!!

Thank you for your time @martenson @martindemko

@martenson
Copy link
Member

@micoleaoo what was the change that worked?

@micoleaoo
Copy link
Author

Sorry, forgot to elaborate.
Removing _singularity from container resolvers in group_vars/galaxyservers.yml, which makes it use our docker.

Containers in Galaxy - Main resolver types

yield a container description suitable for singularity if suffixed by _singularity and docker otherwise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants