Introduction

Assumptions

1. All the hardware are Uniform
   1. Same number of NICs with same PCI ids
   2. Same number of disks with same addresses.
2. Everything is named and their names are used for reference - In Airship, the name if the filename is not important, but the name in the 'schema' (found in schema/metadata/name) is important.

Deployment Configuration and Strategy

This section is added mainly for the completeness purposes. User may chose to configure these values  - only if it is required. For example, with  slow-internet access site, some timeouts may be modified. Or, If user wants to perform some check in-between two actions. 

node01

ucp_control_plane: enabled

control

rack01

Typical Ordering of groups is shown below. 

 __________     __________________
| ntp-node |   | monitoring-nodes |
 ----------     ------------------
     |
 ____V__________
| control-nodes |
 ---------------
     |_________________________
         |                     |
   ______V__________     ______V__________
  | compute-nodes-1 |   | compute-nodes-2 |
   -----------------     -----------------

Profiles

There are two important categories of profiles that the user should create to match their environment:

1. Hardware ( site/<site_name>/profiles/hardware/<profile_name>.yaml)
2. Host site/<site_name>/profiles/host/<profile_name(s)>.yaml

Hardware Profile

Under the hardware profile, user can provide details about the server, and few device (n/w and disk) aliases. User can contact the administrator to obtain this information - else, one has to obtain this information from the 'lshw' command.  For example: sudo lshw -c network -businfo  - to know the NIC names and PCI Ids. Once the user has the hardware information, it can be configure following parameters:

Server:

Device-Aliases:

NICs:

User can categorize the NICs in the hardware as control-plane nics or dataplane nics. In each category he can have one or more NICs.  For example, he can define ctrl_nic1, ctrl_nic2, ctrl_nic3, and data_nic1, data_nic2, data_nic3, etc.  It is better to use names that are self-explanatory - for example, if you have a separate NIC for PXE, name it as pxe_nic. This categorization will be referred in the host-profiles.  For every NIC defined, the below information can be configured. 

Disks:

The Disks can be either bootdisk or datadisk(s). Similar to NICs, the self-explanatory names should be choosen. For example, cephjournal1 can be the name for one of the disks use as one the ceph journals.

For every disk defined, the below information can be configured:

Others

Host Profiles

The host profiles Following things are covered:

1. Mapping NICs of the host the Networks it would belong to. NOTE: For definition of network please refer to Networks section below.
2. How the Bootdisk is partitioned.
3. What all software components are enabled on the particular host.
4. What hardware profile that host is using.
5. Platform specific configuration for the host.

For majority of the cases, you only need two host profiles - Dataplane and Control Plane. Of course, the user can create more than 2 and use it accordingly. The below table summarizes the configurable parameters for the host profiles.

Note: One host profile can adopt values from other host profile. It just have to add

Nodes

This is defined under Baremetal. Node network attachment can be described in a HostProfile or a BaremetalNode document. Node addressing is allowed only in a BaremetalNode document.

Hence, this focuses mostly on addressing. Nodes adopts all values from the profile that it is mapped to and can then again override or append any configuration that is specific to that node. 

Separate schema is created for each and every node. That is the below table contents are repeated for each and every node of the deployment.

*: Array of Values.

Network Definition

Network

Network Link

Software

Recently openstack services are deployed as containers, and to manage these containers various container management platforms such as Kubernetes are used. 

Airship too uses the approach of openstack on Kubernetes (OOK). For deployment/configuration of services/applications/pods (in this case Openstack, monitoring, etc.) on Kubernetes, users have two options (a) Kolla-Kubernetes (b) Openstack Helm. Both the options uses helm for packaging the Kubernetes definitions for each service. However, openstack helm uses helm charts, whereas kolla-kubernetes uses  uses ansible for deployment/orchestration. Airship uses the former option - helm charts. Accordingly, under software, user configurations will fall under two important categories - Charts and Configurations.

Charts

Kubernetes

For Kubernetes system (Namespace: kube-system), user just has to do some substitutions for the control nodes. In this definition, list of control plane nodes (i.e. genesis node + master node list) on which calico etcd will run and will need certs is created.  It is assumed that Airship sites will have 3 control plane nodes, so this should not need to change for a new site. User only has to perform some substitutions..

First he has to create a mapping: The mapping would be:

Undercloud Platform

Ceph

Openstack helm Infra

This includes configuring parameters of various infrastucture components, such as elasticsearch, fluentbit, fluentd, grafana, ingress, mariadb, prometheus.

User can leave all the values as is.

Open Stack Helm - Compute Kit

Under this, there are three important configurations - 

1. Libvirt:
   1. Network Backend: openvswitch or sriov. 
2. Neutron
3. Nova

Tenant-Ceph

Config

Under this configuration, user can only set the region name for openstack helm.

PKI-Catalog

Secrets

Publickeys of the Users.

Path: site/<site_name>/secrets/publickey/<username>_ssh_public_key.yaml

The public key of the user is added as 'data'.

Passphrases of the users

Path: site/<site_name>/secrets/publickey/<username>_crypt_password.yaml

Put a passphrase for the user as 'data'.

Actions

Rack

Region