---
tags: Discussion
---
# Discussing Phases, Plans and "States"
[TOC]

Before we talk about phases, lets define a state , meaning a collection of phases articulating a common purpose on the lifecycle as a state. I claim that states are different than phase plans given that they just indicate an overalll purpose for a particular collection of phases or a plan.
A plan is a colllection of phases that articulate a complete lifecycle.

## States

At a high level these are the states

| State | What is happening |
| -------- | -------- |
| Initialize | Essentially get airshipctl, pull documents etc. |
| Prepare | Validation, Initilization type activities |
| Physical Validation | Validate Target Infrastructure Hardware |
| Ephemeral | Deploy, Configure and Use the ephemerall cluster |
| Target Lifecycle | Configure, and Scale Target Cluster |
| Target Workload Lifecycle | Deploy Services for teh Target Cluster |
| Subcluster Lifecycle | Deploy Subclusters|
| Subcluster Workload Lifecycle |Deploy Sub Cluster level Infrastcuture and Services |
| Subcluster Tenant Workloads | Lifecyce for the applications on the subcluster |

:::warning
During some of these states we need to perform activities that are not necessarily articulated as a phase. i.e. validate hardware, which is TBD wha it looks like, debatable as to wheter its something driven by a phase articulated by driving a container image with a collection of redfish commands , analysis and results. Or some extension to airshipctl, regardless this is Airship v3 scope.

:::
### Prepare State
Actuate actions such as gathering the documents, validating them.
Deal with the secrets if needed i.e. generate them, build images as needed.
These state does not fully need to be repeated every time.
Parts of it might be required for updates or upgrades .

### Physical Validation State
These is intended to provvide validation testing for the infrastructure
such as the examples below. Given the ability to configure some of these
aspects eventually to Metal3 and Ironic, theh need to validate or tests
some of the examples below will subside.

* Local Hardware Verification
* Machine, CPU, Manufacturer, RAM, Product Name, Bonding, NIC port assignments
* North-South Network Connectivity
* IP endpoint and TCP/UDP port flow validation checks
* MTU Validation
* Validation Over Jumbo Frames expectations, i.e. MTU 9000
* Check Raid Devices
* Checks the Raid Configuration on the Server

### Ephemeral Lifecycle State
During these state we execute phases that bootstrap the ephemeral host
all the way to sing the cluster on the host to initialize the control
plane in the target cluster.

### Target Lifecycle State
Durind tehse state we execute phjases that complete the fully realized target control. Meeans the cluster will be fly scaled. It will linclude all aspects for the infrastcuture management it requires.
Infrastructure would be elements that the paltform uses to manage itself , or requires to deploy these infrstcuture elements, such as :
* CAPI
* Helm Operator
* CNI
* CSI

### Target Workload Lifecycle State
During these phase we deliver services to the target cluster. A service is a cpability it provides to the intended targets of tegh custer, as well as soem core services that might be needed by the target cluster for management reasons. Examples would be :
- Openstack Helm
- LMA Stack
- Other services, i.e., if we needed to deliver a platform offered S3 service, we could configure it here.
- Extension to the basic CNI would go here, i.e Multus

### Subcluster Lifecycle State
These state drives the construction of subclusters when appropriate.
Incluuding identifying vBMH's to the complegte configuration and scale
of a subcluster .

### Subcluster Workload Lifecycle State
These state drives delivery of the infrastcture and services it
might provide.
- Services here refers to items such as MinIO S3 services
- Infrastructure wold be things like Storage Class definitions, etc.

### Subcluster/Tenant Workloads State
These state is an abstraction that starts the moment a subcluster is
available to a tenant, or whenever a baremetal cluster is ready to
allow tenants to interact with the cluster. At this point a tenant
is given the appropriate credentials (with appropriate Auth/AuthZ
privileges) and enddpoint for a cluster . The tenant is responsible
for managing the lifecycle of their applications any way they desire.
Conceptualy they would be able to use airship phase document approach
if they choose to, but its not mandatory.

## Phases

The image below is a depiction of the potential target for a collection of phases that deliver a complete end to end cycle.

:::warning
**WAIT ISSUE** : Missing are some of the interim "validation states", to be defined using the generic container interface. These validation states are required after the deployment of phases that cannot abide with the wait logic provided by the phase executors. Common reason is the inability of the artifacts been deployed to provide adequate status state.
:::


### Prepare Phases

| Phase | Purpose |
| -------- | -------- |
| document validate | |
| secret-generate | |
| generate iso | |
| generate qcow | |

### Physical Validation Phases

| Phase | Purpose |
| -------- | -------- |
| baremetal validate "test X" | |
| baremetal validate "test suite" | |

### Ephemeral Lifecycle Phases

| Phase | Purpose |
| -------- | -------- |
| remotedirect-ephemeral | |
| initinfra-networking-ephemeral | |
| initinfra-ephemeral | |
| clusterctl-init-ephemeral | |
| controlplane-ephemeral | |

### Target Lifecycle Phases

| Phase | Purpose |
| -------- | -------- |
| initinfra-networking-target | |
| initinfra-target | |
| clusterctl-init-target | |
| clusterctl-move | |
| workers-target | |
| workers-classification | |

### Target Workload Lifecycle Phases

| Phase | Purpose |
| -------- | -------- |
| workload-target | SIP+Vino could be here , its articulated as a composite if you need to use it or not|
| workload-config-target | CR's.. |

Single phase that is a collection of artifacts for workloads.
We would use the manifests structure using composites and types to adequately incorporae variations as neededd .
i.e. MultiTenant type has no osh
Other type like Anuket(CNTT) : would include OSH composites and functions in the type definition for the wlorkload-target phase.

### Subcluster Lifecycle Phases

| Phase | Purpose |
| -------- | -------- |
| platform-initinfra | |
| controlpane | |
| workers | |

### Subcluster Workloads Lifecycle Phases

| Phase | Purpose |
| -------- | -------- |
| initinfra | |
| workload | |

### Subcluster/Tenant Workloads Phases
| Phase | Purpose |
| -------- | -------- |
| workload | Tenant applications are delivered via these phases |

:::warning
The ultimate goal is to conceptally hve a handfull of phases that can be reused in different contexts.

We had a discussion abot potentially enhancing metadat.yaml

phase:
  path: manifests/site/test-site/phases
  docEntryPointPrefix: manifests/site/test-site
  ???Use ClusterName???
inventory:
  path: manifests/site/test-site/host-inventory

:::danger

Would change https://github.com/airshipit/airshipctl/blob/master/pkg/phase/helper.go
helper.phaseEntryPointBasePath = filepath.Join(helper.targetPath, helper.phaseRepoDir,
helper.metadata.PhaseMeta.DocEntryPointPrefix) + <ClusterName>
:::

Th ebelow patchsets introdces an interim solution to deal with aspects of the WAIT ISSUE mentioned above.

https://review.opendev.org/c/airship/airshipctl/+/774548/13/tools/deployment/33_cluster_move_target_node.sh

---
kind: Phase
metadata:
  name: initinfra-ephemeral
steps:
  - apply-initinfra-resources
  - wait-for-nodes
  - report-steps
---
kind: phase-step
metadata:
  name: applyinitinfra-resources
executorRef:
  kind: kubernetes-apply
entrypoint:...
---
kind: PhasePlan
metadata:
  name: greenfield
phases:
- initinfra-ephemeral
- control-plane

:::

## Plans