Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

CLI control for wrapper scripts #503

Open
marcodelapierre opened this issue Mar 3, 2022 · 4 comments
Open

CLI control for wrapper scripts #503

marcodelapierre opened this issue Mar 3, 2022 · 4 comments

Comments

@marcodelapierre
Copy link
Contributor

marcodelapierre commented Mar 3, 2022

Low priority, but just as it's fresh on top of my head :-D

Would it be useful to have a Client toggle?

--wrapper-scripts true/false

I was thinking it because people may want to use wrappers only for some containers....?
But on the other hand, I am not sure whether it's worth cluttering the Client with this one


Update by @vsoch 3/3/2022: we can work on this alongside a set of client commands for wrappers too, e.g., from #495

We will eventually want an shpc wrapper command to:

  • generate custom wrappers for container already installed
  • list wrappers available for aliases, vs those selected via config
@vsoch
Copy link
Member

vsoch commented Mar 3, 2022

That’s a great idea! What if we generalize to do a -c to change any config value on the fly?

@marcodelapierre
Copy link
Contributor Author

wow, massive, love it!

@marcodelapierre
Copy link
Contributor Author

Update on this one: I think the -c idea is great to provide highly fine grained control in a simple way.

However I think that, in addition, it would be good to provide a dedicated flag for wrapper scripts (similar to symlink tree in #502), for the same reason: I can think of scenarios where one may want to generate scripts only for certain containers (eg MPI applications), while being ok with shell aliases for the others.

A bit of background if you're interested: I think this can be the case for workstations where no job scheduler is present, or for clusters using particular schedulers that don't require prepending a scheduler executable to EVERY application (eg PBS).
The specific case in our centre is different and we'll generate wrappers for all applications: we have the Slurm scheduler, for which the best setup is one where users ALWAYS prepend srun to every application launch.

This being said, last word to you :)

@vsoch
Copy link
Member

vsoch commented Mar 4, 2022

oh that totally makes sense! So I think this would make sense to work with alongside #495 - let me add notes from there here and I'll close the issue over there.

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

No branches or pull requests

2 participants