Beta documentation versions are available at https://susedoc.github.io/, where all commits to main and maintenance branches are automatically built.
Branches
Table 1. Overview of important branches
Name
Purpose
main
Current working branch
maintenance/*
Maintenance for released versions
On Feb 20, 2021, we switched to a new default branch.The default branch is now called main.
Use the main branch as the basis of your commits/new feature branches.
How to update your local repository
If you created a local clone or GitHub fork of this repo before Feb 20, 2021, do the following:
git branch -m master main
git fetch origin
git branch -u origin/main main
git pull -r
Reporting bugs
Bugs are collected on https://bugzilla.suse.com.
If possible, please check for duplicates before creating a new report.
When creating a new report, use SUSE Linux Enterprise HPC as the product, and in the next step select the version.
Select Documentation as the component.
Contributing
Thank you for contributing to this repo. Please adhere to the following guidelines when creating a pull request:
If you are contributing to the most recent release (currently SLE-HPC 15 SP4), create your pull request against the main branch.
This branch is protected.
If you are contributing to a previous release, create your pull request against the respective maintenance/<RELEASENUMBER> branch.
These branches are also protected.
Make sure all validation (GitHub Actions) checks are passed.
For your pull request to be reviewed, tag relevant SMEs from the development team (if applicable) and a member of the SLE-HPC doc team: Tahlia Richardson (@tahliar).
Note
If your pull request has multiple files and reorganisation changes, please build locally using DAPS or daps2docker (see instructions below) to verify and build the files.
GitHub Actions only validates, and does not ensure the XML builds are correct.
Implement any required changes, or fix any merge conflicts if relevant.
If you have any questions, ping a documentation team member in #team-suse-docs on Slack.
SUSE documents are generally built with DAPS (package daps) and the SUSE XSL Stylesheets (package suse-xsl-stylesheets).
Ideally, you should get these from the repository Documentation:Tools.
However, slightly older versions are also available from the SLE and openSUSE repositories.
Building documentation
If you are interested in building DAPS documentation (defaulting to HTML and PDF), you can either use DAPS directly or use daps2docker. Both tools only work on Linux.
Use daps2docker if you use any Linux distribution that includes Docker and Systemd, want to be set up as quickly as possible, and only want to build HTML, PDF, or EPUB.
Use DAPS directly if you are using a recent version of openSUSE, and want to use any of the advanced features of DAPS, such as building Mobipocket or spell-checking documents.
@lproven It appears that Egbert accidentally pushed three commits to a (newly-created) master branch some time in April. Could you check whether these commits are still relevant for main? (If you have time.)
@tahliar - I've read thru it and compared to the upstream documentation:
it seems like a lot of other prerequisites are to me met in order to make this work. https://slurm.schedmd.com/pam_slurm_adopt.html
Either @mslacken or I will have to test this out again on a compute node and see what else is required to make this work. It seems this conflicts with systemd-logind, however, not running this may have further implications.
Would it make sense to move the "HPC user libraries" chapter (and maybe also the spack chapter) to a separate guide called Technical Reference or Developer Guide or something similar?
<para>What is the difference between the state <literal>down</literal> and <literal>down*</literal>?</para>
</question>
<answer>
<para>
When a node is marked as <literal>down</literal> this means that the node is not reachable due to network issues or the <literal>slurmd</literal> is not running. In the <literal>down</literal> state the node is reachable, but the node was rebooted unexpectedly, the hardware does not match the description in <filename>slurm.conf</filename> or a healthcheck configured with the <literal>HealthCheckProgram</literal>.
@mslacken@e4t The documented command to upgrade slurm is zypper install --force-resolution slurm_VERSION, e.g. slurm_20_11. This means you need to know the version number to include it in the command.
How does the admin find out what the new version number is? From update advisories? Or is there a search command you can run to find out?
SLE-12488 lists basic documentation requirements for HPC. I want to mark it as Done now that the Administration Guide exists, but I don't want to miss any items that still need to be done.
Here is the list of items and their status:
Admin:
Installation and configuration of the workload manager [Done]
Provisioning of compute nodes, document clustduct [DOCTEAM-158]
List available HPC libraries, describe their installation features [Done] Does it need to be improved/expanded?
Describe Installation of toolchains and libraries [Done] Does it need to be improved/expanded?
Describe available admin tools [Done and Done] Are any missing?
Considerations about how to set up RDMA [SLE-11046]
User:
Interact with the workload manager [Done] Does it need more?
Use environment modules [Done?] Is this adequately covered?
Check what software components are available [I'm not sure if we have this?]
There is a draft quick start guide in PR #10, written in February 2021. It was still a WIP and is now out of date.
(PDF build for reference: art-hpc-install_color_en.pdf)
Here are some notes to start working towards a new installation guide:
Basic cluster:
One management server with HPC Management Server role
Two compute nodes with HPC Compute Node role
Optional nodes:
Additional management servers
Additional compute nodes
Storage node
Database node
There's also a system role called HPC Development Node. Should we give guidance on when to use this?
Install procedure in original draft guide (PR #10):
Prepare management server:
Install SLE with HPC Management Server role
Set up genders database
Set up SSH access
Set up network storage
(Note: these steps in the draft assume that the compute nodes exist already. There's no step for installing them. So in a future draft these steps should go after setting up the nodes.)
Prepare cluster:
Install munge and distribute key
Set up and sync NTP
Sync genders database
Add NFS mount option
Install slurm
Latest install procedure for new guide (needs review):
Prepare management server:
Install SLE with HPC Management Server role
Which other setup tasks need to be done manually before setting up the compute nodes?
Prepare compute nodes:
Deploy compute nodes with clustduct
How much does clustduct do? Seems like it can install the nodes? Does it create VMs? Would this mean a prerequisite is to have libvirt installed? What about bare metal nodes (is anyone likely to have those)?
The first step would just be a link to the SLES Upgrade Guide, but then Slurm needs to be upgraded manually. Are there any other HPC-specific upgrade or post-upgrade tasks that would make a guide (or article) worthwhile? Maybe you can use pdsh to help upgrade the compute nodes?
@mslacken@e4t Could you take a look at this line and check whether this is supposed to mean the Slurm database or slurmdbd?
The original wording had the clearly typo'd slurmbd [note the position of b and d], this was changed to slurmdb since, but I am not sure that that change was correct.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent