1 Introduction
2 Process
3 Preparation
4 Assumptions
5 Authoring: Customizing the Parameters
- 5.1 Deployment Configuration and Strategy
- 5.2 Profiles
  - 5.2.1 Hardware Profile
    - 5.2.1.1 Server
    - 5.2.1.2 Device-Aliases
      - 5.2.1.2.1 NICs
      - 5.2.1.2.2 Disks
    - 5.2.1.3 Others
  - 5.2.2 Host Profiles
- 5.3 Nodes
- 5.4 Network Definition
  - 5.4.1 Network
  - 5.4.2 Network Link
- 5.5 Software
  - 5.5.1 Charts
    - 5.5.1.1 Kubernetes
    - 5.5.1.2 Undercloud Platform
    - 5.5.1.3 Ceph
    - 5.5.1.4 OpenStack Helm Infra
    - 5.5.1.5 OpenStack Helm - Compute Kit
    - 5.5.1.6 Tenant-Ceph
    - 5.5.1.7 Config
- 5.6 PKI-Catalog
- 5.7 Secrets
  - 5.7.1 Publickeys of the Users.
  - 5.7.2 Passphrases of the users
- 5.8 Boot Actions
- 5.9 Rack
- 5.10 Region
6 Generating Certificates
7 Publishing

Introduction

This document provides instructions for creating Airship manifests for new sites.

Process

The process of creating manifests that would be used for deployment involves the following steps:

Preparation - Cataloging the hardware, network topology, public keys, and so on.
Authoring - Customizing the templates using the information collected in the Preparation phase.
Auto-Generation - Generating certificates.
Publishing - Publishing to OPNFV-Airship's Repository.

Preparation

The user needs to collect the following information before starting the authoring process.

IPMI details of the Nodes. For Intel pods, this information is available in the wiki. Example: Intel POD15
Disk Information. User can boot into any system and run this command: sudo lshw -c disk
PCI IDs of NICs. User can boot into any system and run this command: sudo lshw -c network businfo
The topology and underlay networking details. For Intel pods, this information is available in the wiki. Example: Intel POD15
Public Keys of Users.
Any custom requirements with regards to software.

Assumptions

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

Authoring: Customizing the Parameters

Deployment Configuration and Strategy

This section is added mainly for completeness. User may choose to configure these values if required. For example, with a slow internet access site, some timeouts may be modified. Or, If user wants to perform some kind of check between two actions.

Parameter	Subcategory-1	Subcategory-2	Description	Example Value

Parameter	Subcategory-1	Subcategory-2	Description	Example Value
physical_provisioner
	deployment_strategy		Name of the strategy to use. User can use the one that is defined in airshipit/treasuremap/global/deployment See below.	deployment-strategy
	deploy_interval		The seconds delayed between checks for progress of the step that performs deployment of servers	30
	deploy_timeout		The maximum seconds allowed for the step that performs deployment of all servers	3600
	destroy_interval		The seconds delayed between checks for progress of destroying hardware nodes	30
	destroy_timeout		The maximum seconds allowed for destroying hardware nodes	900
	join_wait		The number of seconds allowed for a node to join the Kubernetes cluster	0
	prepare_node_interval		The seconds delayed between checks for progress of preparing nodes	30
	prepare_node_timeout		The maximum seconds allowed for preparing nodes	1800
	prepare_site_interval		The seconds delayed between checks for progress of preparing the site	10
	prepare_site_timeout		The maximum seconds allowed for preparing the site	300
	verify_interval		The seconds delayed between checks for progress of verification	10
	verify_timeout		The maximum seconds allowed for verification	60
kubernetes
	node_status_interval
	node_status_timeout
kubernetes_provisioner
	drain_timeout		Maximum seconds allowed for draining a node	3600
	drain_grace_period		Seconds provided to Promenade as a grace period for pods to cease	1800
	clear_labels_timeout		Maximum seconds provided to Promenade to clear labels on a node	1800
	remove_etcd_timeout		Maximum seconds provided to Promenade to allow for removing etcd from a node	1800
	etcd_ready_timeout		Maximum seconds allowed for etcd to reach a healthy state after a node is removed	600
armada+
	get_releases_timeout		Timeout for retrieving Helm charts releases after deployment	300
	get_status_timeout		Timeout for retrieving status	300
	manifest+		Name of the manifest document that the workflow will use during site deployment activities	'full-site'
	post_apply_timeout			7200
	validate_design_timeout		Timeout to validate the design	600
Deployment-Strategy
groups			Named sets of nodes that will be deployed together
	name		Name of the group	masters
	critical		If this group is required to continue to additional phases of deployment	true
	depends_on		Group names that must be successful before this group can be processed	[]
	selectors		A list of identifying information to indicate the nodes that are members of this group. Each selector has following 4 filter values
		node_names	Name of the node	`node01`
		node_labels	Label of the node	`ucp_control_plane:enabled`
		node_tags	Tags in Node	`control`
		rack_names	Name of the rack	`rack01`
	success_criteria		A list of identifying information to indicate the nodes that are members of this group. When no criteria are specified, it means that no checks are done. Processing continues as if nothing is wrong
		percent_successful_nodes	The calculated success rate of nodes completing the deployment phase.	75 would mean that 3 of 4 nodes must complete the phase successfully
		minimum_successful_nodes	An integer indicating how many nodes must complete the phase to be considered successful	3
		maximum_failed_nodes	An integer indicating a number of nodes that are allowed to have failed the deployment phase and still consider that group successful.	0

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:

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

Hardware Profile

Under the hardware profile, user can provide details about the server, and a few device (network and disk) aliases. User can contact the administrator to obtain this information. Otherwise, one has to obtain this information from the 'lshw' command. For example, to know the NIC names and PCI IDs: sudo lshw -c network -businfo

Once the user has the hardware information, it is used to configure the following parameters:

Server

Parameter	Description	Example Value
vendor	Vendor of the server chassis	Intel
generation	Generation of the chassis model	'4'
hw_version	Version of the chassis model within its generation	'3'
bios_version	The certified version of the chassis BIOS	'SE5C ....
boot_mode	Mode of the default boot of hardware - bios, uefi	bios
bootstrap_protocol	Protocol of boot of the hardware - pxe, usb, hdd	'pxe
pxe_interface	Which interface to use for network booting within the OOB manager, not OS device	0

Device-Aliases

NICs

User can categorize the NICs in the hardware as either control-plane NICs or dataplane NICs. There can be one or more NICs in each category. For example, the following could be defined: ctrl_nic1, ctrl_nic2, ctrl_nic3, and data_nic1, data_nic2, data_nic3, and so on. 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.

Parameter	Description	Example Value
address	The PCI address of the NIC	0000:04:00.0
dev_type	Description of the NIC	'I350 Gigabit Network Connection'
bus_type	The bus supported	'pci'

Disks

The disks can be either bootdisk or datadisk(s). Similar to NICs, self-explanatory names should be chosen. 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:

Parameter	Description	Example Value
address	The bus address of the disk	0:2.0.0
dev_type	Description of the disk.	'INTEL SSDSC2BB48'
bus_type	The bus supported	'scsi'

Others

Parameter	Subcategory-1	Subcategory-2	Example Value
cpu_set
	kvm		'4-43,48-87'
huge_pages
	dpdk
		size	'1G'
		count	32

Host Profiles

The following items are covered:

Mapping NICs of the host to the networks it would belong to. NOTE: For definition of network, please refer to Networks section below.
How the Bootdisk is partitioned.
Which software components are enabled on a particular host.
What hardware profile that host is using.
Platform-specific configuration for the host.

For the 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 them accordingly. The below table summarizes the configurable parameters for the host profiles.

Note: One host profile can adopt values from other host profile.

Parameter Category	Subcategory-1	Subcategory-2	Subcategory-3

Parameter Category	Subcategory-1	Subcategory-2	Subcategory-3

Airship Manifest Creation For New Sites