...
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.
| Parameter | Sub-Category-1 | Sub-Category-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 | verify_interval | verify_timeout | ||
| 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 | ||||
| removeremove_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 | get_status_timeout | timeout for Retrieving Helm charts releases after deployment | 300 | |||
| get_status_timeout | timeout for retrieving status | 300 | ||||
| manifest+ | The name of the manifest document that the workflow will use during site deployment activities | 'full-site' | ||||
| manifest+ | 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 | ----------------- -----------------
...
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
| Parameter Category | Sub |
|---|
| Category |
|---|
| 1 | Sub Category 2 | Sub-Category-2 | Sub-Category-2 | Description | Example Value 1 |
|---|
| hardware_profile | NA | NA | The hardware profile used by the host | intel_2600.yaml | ||
| primary_network | NA | NA | The main network used for administration | dmz | ||
| Interfaces | NA | NA | Define each and every interfaces of the host in detail. | |||
| Name | NA | Name of the Interface | dmz |
| , data1 | ||||
| device_link | The name of the network link. | dmz |
| , data1 | ||||
| slaves | NIC Aliases | ctrl_nic1 |
| , data_nic1 | ||||
| networks | The networks this interface belongs to. | dmz |
- private
-physical_devices
| , private, management |
Nodes
| storage | ||||||
| physical_devices | ||||||
| labels | ||||||
| volume_group | ||||||
| partitions* | ||||||
| name | ||||||
| size | ||||||
| part_uuid | ||||||
| volume_group | ||||||
| labels | ||||||
| bootable | ||||||
| filesystem | ||||||
| mountpoint | ||||||
| fstype | ||||||
| mount_options | ||||||
| fs_uuid | ||||||
| fs_label | ||||||
| volume_groups | ||||||
| vg_uuid | ||||||
| logical_volumes* | ||||||
| name | ||||||
| lv_uuid | ||||||
| size | ||||||
| filesystem | ||||||
| mountpoint | ||||||
| fstype | ||||||
| mount_options | ||||||
| fs_uuid | ||||||
| fs_label | ||||||
| platform | ||||||
| image | ||||||
| kernel | ||||||
| kernel_params | ||||||
| metadata | ||||||
| tags* | ||||||
| owner_data | ||||||
| rack | ||||||
| boot_mac | ||||||
| host_profile | ||||||
| hardware_profile | ||||||
| primary_network | ||||||
| interfaces | ||||||
| device_link | ||||||
| slaves* | ||||||
| networks* | ||||||
| oob | The ipmi OOB type requires additional configuration to allow OOB management | |||||
| network | which node network is used for OOB access. | oop | ||||
| account | valid account that can access the BMC via IPMI over LAN | root | ||||
| credential | valid password for the account that can access the BMC via IPMI over LAN | root | ||||
| spec | host_profile | Name of the HostProfile that this profile adopts and overrides values from. | defaults | |||
| metadata | ||||||
| owner_data | ||||||
| <software-component-name> enabled/disabled | openstack-l3-agent: enabled |
Nodes
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.
| Parameter Category | Sub-Category-1 | Sub-Category-2 | Sub-Category-3 | Sub-Category-4 | Description | Example Value |
|---|---|---|---|---|---|---|
| addressing* | Contain IP address assignment for all the networks. It is a valid design to omit networks from this, and in that case the interface attached to the omitted network will be configured as link up with no address | |||||
| address | It defines a static IP address or dhcp for each network a node should have a configured layer 3 interface on. | 10.10.100.12 or dhcp | ||||
| network | The Network name. | oob, private, mgmt, pxe, etc. | ||||
*: Array of Values.
Network Definition
...