OpenHPC Documentation

repository·4.x·Indexed 21 days ago

https://github.com/openhpc/ohpc

A community-driven collection of building blocks for deploying and managing High-Performance Computing (HPC) Linux clusters. Includes guides for release series 2.x, 3.x, and 4.x targeting EL8, EL9, EL10, Leap, and openEuler. Features documentation on containerized Slurm clusters, package update monitoring via check_for_package_updates.py, and a Markdown-based installation recipe system supporting various provisioners (Warewulf, OpenCHAMI, Confluent) and architectures.

Tokens
12K
Snippets
21
Records
30
Agent score
77%

What's inside OpenHPC

  1. Overview of OpenHPC components

    4.x

    OpenHPC provides a collection of pre-built ingredients for deploying and managing HPC Linux clusters. The stack includes:

    • Provisioning tools
    • Resource management
    • I/O clients
    • Runtimes
    • Development tools
    • Containers
    • Scientific libraries
  2. Map custom upstream names using RELEASE_MONITORING_MAP

    4.x

    If a package's upstream name differs from its OpenHPC name, you can map it to a release-monitoring.org project name or ID in the RELEASE_MONITORING_MAP dictionary within the script. Use the id:<number> format for ambiguous names.

    RELEASE_MONITORING_MAP = {
        "R": "id:386062",
        "omb": "osu-micro-benchmarks",
        "valgrind": "id:13639",
        ...
    }
    RELEASE_MONITORING_MAP = {
        "R": "id:386062",
        "omb": "osu-micro-benchmarks",
        "valgrind": "id:13639",
        ...
    }
  3. Select the correct OpenHPC release series for your OS

    4.x

    OpenHPC releases are categorized into series that target specific major Linux distributions. Choose the series that matches your target operating system:

    • 2.x series: Targets EL8 and Leap15.
    • 3.x series: Targets EL9, Leap 15, and openEuler 22.03.
    • 4.x series: Targets EL10 and openEuler 24.03.
  4. How Config Inheritance Works

    4.x

    Configuration files are merged in a specific order to build the final system state. The hierarchy follows this precedence (later items override earlier ones):

    1. base.yaml (Global defaults like ohpc_version and boolean flags)
    2. Distro family (e.g., el10.yaml)
    3. Distro (e.g., rocky.yaml)
    4. Architecture (e.g., x86_64.yaml)
    5. Provisioner (e.g., warewulf.yaml)
    6. Scheduler (e.g., slurm.yaml)
    7. Recipe overrides (the .yaml file in the recipes/ directory)

    Boolean flags (e.g., is_x86_64, is_warewulf) are defined as false in base.yaml and set to true in their respective specific config files. These flags are used by Jinja2 templates for conditional content rendering.

  5. Understand the OpenHPC Recipe Architecture

    4.x

    An OpenHPC recipe is a combination of two files located in recipes/ that define a specific system configuration:

    1. *.conf: An ordered list of YAML configuration files from the config/ directory that are merged together.
    2. *.yaml (Optional): Per-recipe overrides. These are primarily used for Confluent recipes to provide values that cannot be derived from the standard configuration hierarchy (e.g., distro_id or distro_iso_image).

    The build process uses yq to perform a deep merge of these files into a single build/*.yaml file, which then serves as the input for documentation generation via mkdoc.py.

    # recipes/rocky10-x86_64-warewulf-slurm.conf
    config/base.yaml
    config/distro/el10.yaml
    config/distro/rocky.yaml
    config/arch/x86_64.yaml
    config/provisioner/warewulf.yaml
    config/scheduler/slurm.yaml
    
    # recipes/rocky10-x86_64-confluent-slurm.yaml
    distro_id: "rocky-10.1-x86_64-default"
    distro_iso_image: "Rocky-10.1-x86_64-dvd1.iso"
  6. Understand the OpenHPC documentation system design

    4.x

    The OpenHPC documentation system is a Markdown-based framework designed to manage installation recipes for High-Performance Computing (HPC) systems. It aims to normalize variable names, reduce duplication, and support a wide variety of distributions (Rocky, AlmaLinux, openEuler, SLES), architectures (x86_64, aarch64), provisioners (Warewulf, OpenCHAMI, Confluent), and schedulers (Slurm).

    A key feature of this system is the ability to generate installation scripts directly from the documentation, using a single Python build tool orchestrated via Makefiles.

  7. Use Proxy Placeholders for Site-Specific Configuration

    4.x

    Since proxy and mirror configurations are highly site-specific, OpenHPC uses static placeholders that are intended to be replaced by a pre-processing script before recipe.sh is executed. These placeholders appear as valid shell comments in the generated script.

    Placeholder Types:

    • #<<< ohpc_proxy:head >>>#: Used for head node setup (CA certs, dnf.conf, etc.).
    • #<<< ohpc_proxy:compute >>>#: Used for compute image or node setup.
    • #<<< ohpc_proxy:image >>>#: Used for OpenCHAMI image-builder configuration.

    Implementation Pattern: To add a new static placeholder, use an ohpc_command marker inside an ohpc_begin block without any ohpc_if wrappers to ensure it is always present for the pre-processor to find.

    <!-- ohpc_begin -->
    <!-- ohpc_comment Configure site authentication (site-specific) -->
    <!-- ohpc_command #<<< ohpc_auth:head >>># -->
    <!-- ohpc_end -->
    #<<< ohpc_proxy:head >>>#
    #<<< ohpc_proxy:compute >>>#
    #<<< ohpc_proxy:image >>>#
  8. Handle Non-IPMI Node Resets via Runtime-Emitted Placeholders

    4.x

    In environments without IPMI (like VMs), compute nodes cannot be reset using ipmitool. Instead, OpenHPC uses runtime-emitted placeholders that the script prints to stdout during execution. An external monitoring process must wrap the script execution to intercept these lines and trigger a hypervisor-level reset.

    Placeholder Format: When the has_ipmi flag is 0, the script emits lines in the following format: #<<< ohpc_reset:index,node_name,bmc_address >>>#

    Example Output:

    #<<< ohpc_reset:0,c1,192.168.1.101 >>>#
    #<<< ohpc_reset:1,c2,192.168.1.102 >>>#

    Implementation Example (Monitoring Wrapper):

    #!/bin/bash
    # Run recipe.sh and intercept ohpc_reset lines to trigger VM resets
    bash recipe.sh 2>&1 | while IFS= read -r line; do
      printf '%s\n' "$line"
      pat='^#<<<[[:space:]]ohpc_reset:([0-9]+),([^,]+),(.+)[[:space:]]>>>#$'
      if [[ "$line" =~ $pat ]]; then
        idx="${BASH_REMATCH[1]}"
        node_name="${BASH_REMATCH[2]}"
        bmc_addr="${BASH_REMATCH[3]}"
        echo ">>> Triggering reset for ${node_name} [${idx}] (${bmc_addr})" >&2
        openstack server reboot --hard "${node_name}"
      fi
    done
    #<<< ohpc_reset:0,c1,192.168.1.101 >>>#
  9. Configure GitHub API token for package checks

    4.x

    To avoid GitHub API rate limits (60 requests/hour) and increase the limit to 5,000 requests/hour, provide a GitHub token. You can do this via an environment variable or a CLI flag.

    Using environment variable

    export GITHUB_TOKEN=ghp_...
    python3 misc/check_for_package_updates.py

    Using CLI flag

    python3 misc/check_for_package_updates.py -t ghp_...
    export GITHUB_TOKEN=ghp_...
    python3 misc/check_for_package_updates.py
  10. Update OpenHPC spec files with new versions

    4.x

    You can use the --update flag to automatically modify spec files when a newer version is detected.

    • For standard packages, the script updates the Version: tag using the specfile library.
    • For GNU compiler components, it updates the corresponding %global macro directly.

    Workflow Recommendation:

    1. Run a dry run (omit --update) to see what would change.
    2. Apply the update using --update.
    3. Review the changes using git diff.

    Examples

    Dry run for cmake:

    python3 misc/check_for_package_updates.py cmake

    Apply updates for cmake:

    python3 misc/check_for_package_updates.py --update cmake

    Review changes:

    git diff components/dev-tools/cmake/SPECS/cmake.spec
    python3 misc/check_for_package_updates.py --update cmake
  11. Copy examples to the cluster project folder

    4.x

    To run provided examples (like MPI tests) inside the container, you must first copy them to the shared /project directory on the openhpc-login node.

    Option 1: Using rsync (Recommended) If you have rsync installed locally, use ./rsync.sh to sync the examples directory to your user's project folder.

    Option 2: Using Docker commands If rsync is unavailable, use docker cp and then fix the permissions inside the container.

    Running an MPI Example: Once copied, navigate to the MPI example directory and execute the run script.

    # Option 1: Using rsync
    ./rsync.sh -av ./examples openhpc-login:/project/$USER/
    
    # Option 2: Using docker cp
    docker cp examples openhpc-login:/project/$USER/
    docker exec -i openhpc-login chown -R $USER:$USER /project/$USER
    
    # Run the MPI example
    cd /project/$USER/examples/mpi
    bash run.sh
  12. Run the OpenHPC 4.x Slurm cluster in a container

    4.x

    This environment provides a single-user cluster for learning and testing Slurm on OpenHPC 4.x with Rocky10. The cluster consists of a head node (openhpc-head), a login node (openhpc-login), and 8 compute nodes (openhpc-node-[0-7]) using shared Docker networking and storage.

    Cluster Architecture:

    • Shared Storage: /project (volume openhpc-container-project) and /scratch (volume openhpc-container-scratch).
    • Non-shared Storage: The /home directory is not shared across containers.

    Setup and Execution:

    1. Container Engine: If using podman instead of Docker, set the CONTAINER environment variable.
    2. Start Cluster: Run ./run.sh. This creates the network, shared storage, and starts the 8 nodes. It will automatically connect you to the login node. Exiting this shell will shut down the cluster.
    3. Accessing Nodes:
      • To connect to the login node from a new terminal: ./ssh.sh.
      • To login to the head node as root: USER=root ./ssh.sh (Note: root access is temporary and lost when ./run.sh is exited).
    4. Cleanup: Run ./delete.sh to remove the cluster network, storage, and container images.
    # Use podman instead of docker
    export CONTAINER=podman
    
    # Build and run the cluster
    ./run.sh
    
    # Connect to the login node from another terminal
    ./ssh.sh
    
    # Clean up everything when finished
    ./delete.sh