Conversation
|
The document should focus on how to start working with the cluster after gaining access. Topics such as policies, access procedures, and related details should be moved to a separate document. This document should provide clear answers to the following questions:
|
|
@MKhlystun: Thank you for the feedback, But there isn't anything related to how SSH works itself, rather 2 commands explaining directly how to connect. These instructions were provided by Alex (yesterday), based on the most recent Email template for access through SSH after one's account approval. I previously wrote a complete guide for Jupyter Notebook, which I don't believe could be truncated to something short and sweet to go under "quickstart", and it would require proper reading by the user (https://docs.starhpc.hofstra.io/software/jupyter-notebook.html). If you think it could be helpful, I can leave a reference to this section under the "Where from here" section. The Jira issue mentioned a "Hello World" Slurm job, and I think the current job is simple and short enough to go under quickstart. Concise and basic explanation is provided for the directives as well. For more complex/custom jobs, I have left a reference to the page which contains a wide variety of Slurm examples in full detail: https://docs.starhpc.hofstra.io/jobs/submitting-jobs.html I think anything too comprehensive defeats the purpose of the page being a quick start. M |
|
As I mentioned to you, please do not include the actual SSH commands with the login node or really discuss SSH at all beyond referring users to read the welcome email for the connection information. The SSH command could be included with placeholders for names of the login node and jump host, but it would likely just be confusing. The point of the quick start guide is to provide the minimum needed for users to do something real on the cluster, such as a minimal working example of using The welcome email is already long, so that's why the quick start guide needs to be separate. But it is not at all meant to replace the welcome email. So there really should be no (or minimal) overlap. The password requirements should not be duplicated for example. |
No description provided.