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

[doc] questions about prerequisite and putting the plugin in Kubernetes cluster #17

Open
antoinetran opened this issue Jul 12, 2024 · 2 comments

Comments

@antoinetran
Copy link
Contributor

Not an issue but doc clarification related to https://intertwin-eu.github.io/interLink/docs/tutorial-admins/deploy-interlink#requirements-1

Due to security and test reasons, I would like to put the interlink slurm plugin directly in the Kubernetes cluster. The plugin would then run sbatch jobs directly from there.

According to the doc, the plugin requires:

  • "a slurm CLI available on the remote host and configured to interact with the computing cluster"
    => I can create a slurm plugin container, with Slurm CLI included
  • a sharedFS with all the worker nodes
    => the Slurm worker nodes already have a sharedFS

My biggest question is: does the interlink slurm plugin needs direct access to the shared FS too? (to get the logs or some result?)

@dciangot
Copy link
Collaborator

Short answer: yes, the plugin does need the fs to get status and logs.

Widening a bit the context, we started to look at a mode in which the plugin can do everything without the shared fs, but since there was no immediate use cases, we did not invest in it.

Nevertheless, recently we started getting to scenarios where the SLURM rest interaction can have a lot of benefits (as you mention), so we are planning to rewamp the activity after the summer. Unless someone come up volunteering to work on it.

@antoinetran
Copy link
Contributor Author

Ok, I am only asking this because this is a workaround for deploying the interlink slurm plugin easily, for test purpose.

But we are also thinking the kubernetes cluster should have access to the shared FS, so this would not be an issue anymore.

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

2 participants