Inventory

Your inventory gathers all the information necessary to bootstrap your installation. It resembles your physical infrastructure and network topology. This page explains its structure and highlights important aspects.

The inventory repository is subdivided into multiple folders. These include:

• inventory
• dhcp-config
• matchbox
• ssh

Inventory configuration

This folder includes all the yaml files to configure the physical servers.

Schema

Every possible inventory configuration option is defined and validated by a schema definition before it is applied. These schema definitions are specific to the COTB version and also follow a specification. Select your target version from the sidebar to the left to read more about possible and required options. The schema declarions themselves are specified using Yamale syntax.

The version specified in common.yml defines which schema is applied across all inventory files.

YAML structure

We expect your directories to have to following layout:

.
├── common.yml
└── nodes
    ├── control01.yml
    ├── control02.yml
    ├── network.yml
    ├── storage01.yml
    ├── storage02.yml
    ├── compute01.yml
    ├── compute01.yml
    ├── compute02.yml
    └── computenodes.yml

The common.yml file is mandatory and follows the schema specification "common". The nodes folder is also mandatory, the files inside can be named arbitrarily. We suggest to create a single file per node. However, they can be grouped into files as desired. For example, all computenodes could be placed into a file called nodes/computenodes.yml

Example (common.yml)

common.yml

version: 1.1.0
customer_name: demo
ssh_authorized_keys:
  - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQ...
password_hash: $6$...
sshd_allow_users:
  - "core@10.*.*.*"
  - "root@10.*.*.*"
container_registry:
  url: registry.gitlab.com
  user: cotb-customers-demos
  password: "..."
matchbox_endpoints:
  demo-a:
    ip: 10.1.3.10
    port: 6331
  demo-b:
    ip: 10.1.3.11
    port: 6331
networking:
  dns: 1.1.1.1

Example (compute nodes)

nodes/computenodes.yml

- name: computenode-01
  interfaces:
    eth1:
      mac: 00:00:00:00:00:00
      type: 1g
      vlan_parent: true #if part of a macvlan
    ethboot:
      ips: 
        - 10.1.0.1/24 
      mac: 00:00:00:00:00:00
      vlan:
        type: macvlan
        parent: eth1
        mode: 2
      type: 1g
    ethdata:
      ips:
        - 10.1.1.1/24
      mac: 00:00:00:00:00:00
      vlan:
        type: vlan
        parent: eth1
        id: 3 # arbitrary but common for data
    ethcontrol:
      ips:
        - 10.1.2.1/24
      mac: 00:00:00:00:00:00
      vlan:
        type: vlan
        parent: eth1
        id: 4 # arbitrary but common for control
      routes:
        - network: 0.0.0.0/0
          gateway: 10.1.1.250
          metric: 1000
      dns: 1.1.1.1
    eth2:
      mac: 00:00:00:00:00:02
      type: 1g
  kubernetes:
    node_ip: 10.1.8.1
    token: f8a2f9cy8s67ea3aaaa2069dr51fdc75
    role: agent
    master_url: https://10.1.8.250:6443
  disk: ssd # disk type
  wipe_disks: false # whether the node shall be complete deleted
  type: computenode 
  canary: red # or green for phased rollouts
  datacenter: prod # arbitrary name used for staging 
  ipmi:
    baudrate: 115200n8 # ipmi interface baud rate

DHCP configuration

This folder contains a Dockerfile and a dhcpd.conf to create specific settings for the DCHP server that integrated PXE as explained in the architecture section. It needs to integrate into your designated boot network

Matchbox

This folder only contains a Dockerfile that is resposible for assembling all the generated configuration artifacts for the inventory. This includes ignition, groups and profiles. Typically, no further configuration is necessary.

SSH

The ssh folder contains keys used for ssh access and includes both ECDSA hostkeys for authentification, as well as SSH keys for authorization.

Hostkeys are used to keep the physical server identity across immutable reboots. If not persisted, this identity would be lost.

The SSH keys are used by OpenStack to enable VM migration. On a technical level, VM migration leverages scp to copy VMs from one host to another.

The folder also contains two helper scripts: generate_host_keys.sh and generate_key.sh. Use these scripts for your convenience to generate missing keys.

Hostkeys script

cd inventory/ssh/
# set $NODENAME according to the node name in your inventory files
./generate_host_keys.sh $NODENAME

This creates the files

• inventory/ssh/hostkeys/$NODENAME/ssh_host_ecdsa_key
• inventory/ssh/hostkeys/$NODENAME/ssh_host_ecdsa_key.pub

SSH script

This script reads the node-list file and generates SSH keys for each node listed there. The node-list file follows a simple name=ipsuffix format. control01=11 for example yields 10.100.1.11 where the last tuple is equivalent to the ipsuffix and the remaining tuples according to your network setup.

The sshkeys folder will subsequently be picked up by a pipeline to generate the OpenStack migration config.