...
To address a large variety of setups, multiple methods of deployment should be supported. Deployment works both on x86_64 and aarch64 hw.
| Method | Pros (current state) | Cons (current state) | Prerequisites |
|---|
| Manual installation | - Full control over each step
- Easy to understand and replicate
- Already available (see next chapter on this page)
| - Requires user intervention
- Requires certain prerequisites be met on cluster nodes apriori
| - preinstalled operating system (Ubuntu 16.04/18.04) on all involved nodes
|
| Script-based installation | - High degree of flexibility via arguments
- Portable
- Can be used in CI/CD, assuming baremetal nodes are pre-provisioned, e.g. for shorter test cycles like a patch verify job where we'd want to avoid reinstalling the operating system each time
| - Implementation currently in progress
- Fixed number of nodes (1 master + 1 worker)
- Requires certain prerequisites be met on cluster nodes apriori
| - preinstalled operating system (Ubuntu 16.04/18.04) on all involved nodes
- user with passwordless sudo access already available on the target nodes
|
| OPNFV-based installer(s) | - Unified and standardized input configuration files (PDF/IDF)
- Can be used in CI/CD
- Can handle OS provisioning on its own, for virtual, baremetal or hybrid PODs
| - Not yet implemented
- Requires hardware descriptor files (PDF/IDF)
| - Jumpserver (installer) node preinstalled
- XDF (PDF/IDF) available for the target lab
|
| Heat stack | | | - Openstack cloud preinstalled
|
| Other installer solutions (e.g. Airship) | - Alignment with industry standard installer solutions for K8s
| - Not implemented
- More complex design and configuration
- Might be overkill for IEC, at least with the current requirements
| |
...