pvc-ansible/group_vars/default/bootstrap.yml

---
# PVC cluster specification for pvcbootstrapd
#
# This configuration is entirely optional, and is not required unless you are using pvcbootstrap
# to deploy the cluster. It must be filled out and committed before connecting any hosts from
# the new cluster.
#
# This example provides a detailed explanation for, and examples of, the various options that can
# be used by this subsystem.
#
# Bootstrap Host Definitions
#
# All hosts to be bootstrapped by the pvcbootstrapd system must be present in this list.
#
# NOTE: Only Redfish-capable BMCs can be automatically provisionned by pvcbootstrapd. Non-Redfish
# BMCs can be used, but they must be pre-configured with a system disk RAID, to boot from network,
# etc. and the per-host TFTP files must be created manually.
#
# Each host is specified by its hardware BMC MAC address, usually available on the system asset
# tag or on some sort of label on the system board.
#
# Under the parent tag are a series of required and optional values, which are self-documented.
#
# System Disks Logic
#
# The key "bootstrap" -> "config" -> "system_disks" specifies the disk(s) that the system will
# be installed to. These disks are specified as a YAML list of one (or more) of the following:
#
#  1. A fixed Linux "/dev" path, for example "/dev/sda" (SCSI/SAS/SATA), "/dev/nvme0n1" (NVMe),
#     "/dev/disk/by-id" (fixed-ID paths), or "/dev/disk/by-path" (fixed-location paths).
#     Generally, the latter options are preferable as they are more consistent and more easily
#     guessed before a Linux operating system is booted, but all are acceptable depending on the
#     disk type.
#
#  2. A "detect:" string, in the form "detect:<name>:<human-readable size>:<id>". Detect strings
#     leverage the "lsscsi" tool in the installer to logically determine the desired block device
#     path from the given information.
#
#     The "<name>" can be any identifier the device will have, for example "INTEL" for an Intel
#     SSD, "SEAGATE" for a Seagate HDD, "DELLBOSS" for a Dell BOSS (Boot-Optimized Storage System)
#     virtual volume, "PERC" for a Dell PERC RAID card, etc. This should usually match something
#     found in the "Vendor" column of "lsscsi" or elsewhere in the output line. Multiple space-
#     separated "words" are supported but should only be used to avoid ambiguity.
#
#     The "<size>" is a human-readable size, usually matching the label size of the disk (e.g.
#     300GB, 800GB, 1.92TB, etc.). This will be matched to within +/- 2% of a real block device
#     in "lsscsi" to find a match.
#     
#     The "<id>" specifies the Nth (0-indexed) match on both the "<name>" and "<size>". So for
#     example, if there are 3x 800GB Intel SSDs, "detect:INTEL:800GB:2" will match the third.
#     Note that this ordering is based on SCSI bus ID, and is thus normally consistent and
#     predictable, but there can be corner cases.
#
#  3. A logical, 0-indexed disk ID detectable by Redfish, for example "0", "1", etc. On systems
#     with support for it, up to two (2), but no more, disks can be specified in this list by
#     these logical IDs. In such a case, the Redfish bootstrap will attempt to find the physical
#     disks at the given IDs on the first storage (RAID) controller and, if found, create a RAID-1
#     virtual disk out of them. This allows easy specification of the situation where you might
#     want, for example, "the first and second disks" to be turned into a RAID-1, with the rest
#     used for other purposes.
#
#     Note that only the 3rd method supports this auto-creation of RAID devices; the first two
#     require an existing (single) disk or virtual device which is visible by Linux. Also note
#     that the PVC installer does not support software RAID-1 for system volumes, though this
#     could be added later.
#
#     Once created, the virtual RAID-1 created using this method will be found via a "detect:"
#     string identical to method 2.
#
# Hooks
#
# Hooks are a series of tasks that are run against one or more nodes in the cluster after the
# completion of the Ansible configuration. These hooks, specified on a cluster-level, can be
# used to automate post-deployment tasks. Hooks are specified as a YAML list of dictionaries.
#
# Each hook is given a "name" which is used in the log output but which is otherwise unimportant.
#
# There are several "type"s of hooks, some of which are specialized for common tasks, and others
# which can be free-form. The primary types are:
#
#   * osddb    Create an OSD DB volume group on a given node from a given block path, specified
#              by one of the first two (2) methods mentioned above for system disks.
#   * osd      Create a storage OSD on a given node from a given block device path, specified by
#              one of the first two (2) methods mentioned above for system disk.
#              If multiple nodes have the same devices, the same task can run against several
#              at once in one task, otherwise they should be run sequentially, per-node.
#   * pool     Create a storage pool on the cluster with the specified number of PGs.
#
#   Note: The above 3 hooks should always be specified in the given order if they are to be used.
#
#   * network  Create a network on the PVC cluster with the specified parameters (see below).
#
#   * script   Run a script on the given host(s). Can be used to run arbitrary commands or other
#              scripts on the remote system.
#              The script may be specified in one of 3 ways:
#                1. A raw YAML block, containing a valid shebang and the contents of the script.
#                   For a single BASH command, this would be something like:
#                     #!/usr/bin/env bash
#                     mycommand
#                2. A "local" source and a "path" to a script to copy to the destination host.
#                   The path may be absolute, or relative to the Ansible repository directory.
#                3. A "remote" source and a "path" to the script on the destination host.
#
#   Note: A script hook will run as the "deploy_user" on the remote system. If you require the
#         command to have root privileges, use "sudo" in the script.
#
# A hook can "target" one or more nodes in the cluster. These are specified by their "node
# hostname" as specified in the "bootstrap" section in a YAML list. The special value "all" can
# be used to represent all nodes in the cluster; if "all" is specified it should be the only value.
#
# The value of "target" is used slightly differently for the osddb, osd, pool, and network (PVC)
# hook types above. For osddb and osd, the list of "target"s will be the nodes that the given
# block device will be created on with the given parameters, but will actually target the API.
# For pool and network hook types, the target is ignored completely and can/should be empty or
# "all" for clarity.
#
# Each hook has a series of "args" which are unique to that particular hook type. These are
# self-documented inline below for each hook type.

# Bootstrap elements
bootstrap:
  # First node
  "d8:d3:85:12:34:56":                  # BMC MAC Address (from asset tag, etc.)
    node:                               # Node information
        hostname: hv1                   # The (short) hostname. Must be present in the pvc_nodes list.
    config:                             # Node configuration
        kernel_options:                 # Additional kernel options for the installer, OPTIONAL
          - console=ttyS1,115200n       # "Use the serial console ttyS1 at 115200 baud"
        release: buster                 # The Debian release to install, OPTIONAL
        mirror: http://ftp.debian.org/debian   # The Debian mirror to use, OPTIONAL
        packages:                       # List of additional packages to install, OPTIONAL
          - ca-certificates             # "Install the ca-certificates package in the target system"
        filesystem: ext4                # The filesystem to use for the system partitions, OPTIONAL
        system_disks:                   # List of system disks to install to
          - "detect:Intel:200GB:0"      # "Find the first 200GB Intel SSD"
    bmc:                                # BMC information
        username: Administrator         # BMC/IPMI administrative username
        password: SuperSecretPassword   # BMC/IPMI administrative password (initial)
                                        # NOTE: This is usually the out-of-box password; the production
                                        # password will be set later by the Ansible roles.
        redfish: yes                    # Can system BMC support Redfish?
                                        # NOTE: This is optional; Redfish will be probed if missing.
  # Second node
  "68:b5:99:12:34:78":                  # BMC MAC Address (from asset tag, etc.)
    node:                               # Node information
        hostname: hv2                   # The (short) hostname. Must be present in the pvc_nodes list.
    config:                             # Node configuration (optional)
        kernel_options:                 # Additional kernel options for the installer, OPTIONAL
          - console=ttyS1,115200n       # "Use the serial console ttyS1 at 115200 baud"
        release: buster                 # The Debian release to install, OPTIONAL
        mirror: http://ftp.debian.org/debian   # The Debian mirror to use, OPTIONAL
        packages:                       # List of additional packages to install, OPTIONAL
          - ca-certificates             # "Install the ca-certificates package in the target system"
        filesystem: ext4                # The filesystem to use for the system partitions, OPTIONAL
        system_disks:                   # List of system disks to install to
          - "0"                         # "Create a RAID out of the first and second physical disks"
          - "1"
    bmc:
        username: Administrator         # BMC/IPMI administrative username
        password: SuperSecretPassword   # BMC/IPMI administrative password (initial)
                                        # NOTE: This is usually the out-of-box password; the actual live password
                                        # will be set later by the Ansible roles.
        redfish: yes                    # Can system BMC support Redfish?
                                        # NOTE: This is optional; Redfish will be probed if missing.
  # Third node
  "18:a9:05:12:45:90":                  # BMC MAC Address (from asset tag, etc.)
    node:                               # Node information
        hostname: hv3                   # The (short) hostname. Must be present in the pvc_nodes list.
    config:                             # Node configuration (optional)
        kernel_options:                 # Additional kernel options for the installer, OPTIONAL
          - console=ttyS1,115200n       # "Use the serial console ttyS1 at 115200 baud"
        release: buster                 # The Debian release to install, OPTIONAL
        mirror: http://ftp.debian.org/debian   # The Debian mirror to use, OPTIONAL
        packages:                       # List of additional packages to install, OPTIONAL
          - ca-certificates             # "Install the ca-certificates package in the target system"
        filesystem: ext4                # The filesystem to use for the system partitions, OPTIONAL
        system_disks:                   # List of system disks to install to
          - "/dev/sda"                  # "Use the disk at /dev/sda"
    bmc:
        username: Administrator         # BMC/IPMI administrative username
        password: SuperSecretPassword   # BMC/IPMI administrative password (initial)
                                        # NOTE: This is usually the out-of-box password; the actual live password
                                        # will be set later by the Ansible roles.
        redfish: yes                    # Can system BMC support Redfish?
                                        # NOTE: This is optional; Redfish will be probed if missing.

# Bootstrap hooks (post-configuration)
hooks:
  - name: "Create OSD database volume on the first NVMe device"
    type: osddb
    target:
      - all
    args:
      disk: "/dev/nvme0n1"              # The disk to be used for the OSD DB volume group

  - name: "Create OSDs on the first 300GB HDD device on each node"
    type: osd
    target:
      - all
    args:
      disk: "detect:LOGICAL:300GB:0"    # The disk to be used for the OSD, first 300GB LOGICAL disk
      weight: 8                         # The weight of the OSD
      ext_db: no                        # Use external OSD DB

  - name: "Create OSDs on the first 800GB  Intel SSD device on each node"
    type: osd
    target:
      - all
    args:
      disk: "detect:INTEL:800GB:0"      # The disk to be used for the OSD, first 400GB Intel SSD
      weight: 4                         # The weight of the OSD, note half of first OSD weight
      ext_db: yes                       # Use external OSD DB
      ext_db_ratio: 0.08                # External OSD DB percentage ratio if different from default 0.05

  - name: "Create storage pool 'vms'"
    type: pool
    target:
      - all
    args:
      name: "vms"                       # The name of the pool
      pgs: 128                          # The number of placement groups (#OSD * ~250 / 3 / 2, round down to 2^n)
      tier: "ssd"                       # The tier of storage devices to use (default, hdd, ssd, nvme if available)

  - name: "Create bridged public network on vLAN 1000"
    type: network
    target:
      - all
    args:
      vni: 1000                         # The PVC VNI (vLAN ID)
      description: "public"             # The network description (no whitespace)
      type: bridged                     # The type of network (bridged or managed)
      mtu: 9000                         # The network MTU

  - name: "Create managed deployment network on VXLAN 10000"
    type: network
    target:
      - all
    args:
      vni: 10000                        # The PVC VNI (VXLAN ID)
      description: "deployment"         # The network description (no whitespace)
      type: managed                     # The type of network (bridged or managed)
      mtu: auto                         # The network MTU; 'auto' and 'default' preserve default
      domain: pvc.local                 # The network domain for DNSMasq
      dns_servers:                      # The remote DNS servers
        - 10.100.100.10
        - 10.100.100.11
      ip4: yes                          # Enable IPv4 networking
      ip4_network: 10.0.0.0/24          # The IPv4 network, required if ip4
      ip4_gateway: 10.0.0.1             # The IPv4 gateway, required if ip4
      ip4_dhcp: yes                     # Enable IPv4 DHCP, required if ip4
      ip4_dhcp_start: 10.0.0.100        # IPv4 DHCP start address, required if ip4_dhcp
      ip4_dhcp_end: 10.0.0.199          # IPv4 DHCP end address, required if ip4_dhcp
      ip6: yes                          # Enable IPv6 networking
      ip6_network: 2001:1234:5678::/64  # The IPv6 network, required if ip6
      ip6_gateway: 2001:1234:5678::1    # The IPv6 gateway, required if ip6

  - name: "Run a quick storage benchmark leveraging node 1 as the runner"
    type: script
    target:
      - hv1
    args:
      script: |
        #!/usr/bin/env bash
        pvc storage benchmark run --yes vms

  - name: "Run a quick Python script on all nodes"
    type: script
    target:
      - all
    args:
      script: |
        #!/usr/bin/env python
        print("Hello, world!")

  - name: "Run a more complex Python script on nodes 2 and 3"
    type: script
    target:
      - hv2
      - hv3
    args:
      source: local                     # Copy the script first from the local system (full path or relative under the Ansible repository)
      path: "scripts/mytask.py"         # This is the path to the script, which must have a valid shebang.

  - name: "Run a more complex BASH script on nodes 1"
    type: script
    target:
      - hv1
    args:
      source: remote
      path: "/usr/local/bin/dostuff"