-
Notifications
You must be signed in to change notification settings - Fork 489
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
176 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,176 @@ | ||
| --- | ||
| title: packet-ipi | ||
| authors: | ||
| - "@displague" | ||
| - TBD | ||
| reviewers: | ||
| - TBD | ||
| approvers: | ||
| - TBD | ||
| creation-date: 2020-08-13 | ||
| last-updated: 2020-08-13 | ||
| status: provisional | ||
| --- | ||
|
|
||
| # Packet IPI | ||
|
|
||
| ## Release Signoff Checklist | ||
|
|
||
| - [ ] Enhancement is `implementable` | ||
| - [ ] Design details are appropriately documented from clear requirements | ||
| - [ ] Test plan is defined | ||
| - [ ] Graduation criteria | ||
| - [ ] User-facing documentation is created in | ||
| [openshift-docs](https://github.com/openshift/openshift-docs/) | ||
|
|
||
| ## Summary | ||
|
|
||
| [Support for OpenShift 4](https://github.com/RedHatSI/openshift-packet-deploy) | ||
| on Packet was initially provided through the user provisioned (UPI) workflow. | ||
|
|
||
| This enhancement proposes adding tooling and documentation to help users deploy | ||
| OpenShift 4 on Packet using the installer provisioned infrastructure (IPI) | ||
| workflow. | ||
|
|
||
| ## Motivation | ||
|
|
||
| Users who want to deploy OpenShift on single-tenant cloud infrastructure in | ||
| facilities where high levels of interconnection are possible, may wish to take | ||
| advantage of the Packet's bare metal and virtual networking infrastructure. We | ||
| can help these users simplify the process of installing OpenShift on Packet by | ||
| introducing an installer-provisioned options that take advantage of various | ||
| models of compute, memory, GPU, or storage classes of devices, hardware and IP | ||
| reservations, virtual networks, and fast direct-attached storage. | ||
|
|
||
| Currently, users who want to [deploy OpenShift on | ||
| Packet](https://www.packet.com/solutions/openshift/) must follow the [OpenShift | ||
| via Terraform on Packet UPI | ||
| instructions][https://github.com/RedHatSI/openshift-packet-deploy/blob/master/terraform/README.md], | ||
| which is not streamlined and can not be integrated into the [Try OpenShift | ||
| 4](https://www.openshift.com/try) workflow. | ||
|
|
||
| ### Goals | ||
|
|
||
| The main goal of the IPI is to grant users an easier path to running Red Hat | ||
| OpenShift 4 on a horizontally scalable bare metal architecture in data centers. | ||
|
|
||
| As a first step, we would create a provisioning installer codebase and a set of | ||
| documented steps. These would enable users to deploy OpenShift with IPI in a way | ||
| that is very similar to UPI but simplifies the process. | ||
|
|
||
| Following other IPI installers, this first step would include | ||
|
|
||
| - Making Packet IPI documentation available here: | ||
| <https://github.com/openshift/installer/blob/master/docs/user/packet/install_ipi.md> | ||
| - Making Ansible playbooks for scripts for oVirt/RHV resource creation available here: | ||
| https://github.com/openshift/installer/tree/master/upi/ovirt | ||
| - Making a CI job executing the provisioning scripts to test the IPI installer | ||
|
|
||
| ### Non-Goals | ||
|
|
||
| It is outside the scope of this enhancement to provide explanations about the installation | ||
| of infrastructure elements that are considered as required and owned by the user (e.g. DNS, | ||
| DHCP, Load Balancer...) | ||
|
|
||
| ## Proposal | ||
|
|
||
| * Define and implement Packet types in the openshift/installer | ||
| * High level variables should include: | ||
| * API Key | ||
| * Project ID | ||
| * Boostrap node variables should: | ||
| * Device plan (defaulting to minimum required) | ||
| * Facility | ||
| * Virtual Networks | ||
| * Cluster creation should include | ||
| * | ||
| * Write documentation to help users configure pre-existing infrastructure | ||
| elements (such as which IPs to reserve in the DNS) | ||
| * Write the UPI documentation linking Ansible playbooks | ||
| * Setup the CI job to have running test suite | ||
|
|
||
| ### Implementation Details/Notes/Constraints | ||
|
|
||
| The implementation of the UPI workflow aims to reproduce the features of the IPI that enable | ||
| users to deploy OpenShift on existing infrastructure. | ||
|
|
||
| The user should be able to specify custom configurations that use the pre-existing | ||
| infrastructure for the installation, such as the domain name, DNS, DHCP, Load Balancer. | ||
|
|
||
| Given the maturity of the oVirt Ansible modules and administrators' familiarity with Ansible, | ||
| we will provide a set of playbooks to automate the configuration and installation process as much | ||
| as possible. | ||
|
|
||
| Depending on the user environment, we will provide instructions and scripts that could help the user: | ||
|
|
||
| * Add mandatory records (A, PTR, SRV) to the user-provided DNS. | ||
| * Upload a specific RHCOS image. | ||
| * Configure a load balancer (HAProxy) | ||
| * Configure a DHCP to assign IP addresses to bootstrap machines | ||
| * Bootstrap VMs | ||
|
|
||
| ### Risks and Mitigations | ||
|
|
||
| This UPI will try to achieve the same results obtained by the automatic and opinionated | ||
| IPI installer, but in a more customizable way using provisioning scripts like Ansible | ||
| and the documentation provided. | ||
|
|
||
| The CI will represent one of the challenging problems. We will need to carefully schedule | ||
| the UPI jobs to minimize their impact on the currently limited CI capacity. | ||
|
|
||
| We cannot exclude that an additional quota must be required to fulfill all the UPI CI needs. | ||
|
|
||
| ## Design Details | ||
|
|
||
| ### Test Plan | ||
|
|
||
| We will use existing UPI platforms, such as OpenStack, AWS, and GCP, as the inspiration for our | ||
| testing strategy: | ||
|
|
||
| - A new e2e job will be created to use the Ansible templates. | ||
| - At the moment, we think unit tests will probably not be necessary. However, we will cover | ||
| any required changes to the existing codebase with appropriate tests. | ||
|
|
||
| ### Graduation Criteria | ||
|
|
||
| The proposal is to follow a graduation process based on the existence of a CI | ||
| running suite with end-to-end jobs. We will evaluate its feedback along with | ||
| feedback from QE's and testers. | ||
|
|
||
| We consider the following as part of the necessary steps: | ||
|
|
||
| - CI jobs present and regularly scheduled. | ||
| - IPI document published in the OpenShift repo. | ||
| - Ansible playbooks exist. | ||
| - End to end jobs are stable and passing and evaluated with the same criteria as | ||
| comparable IPI providers. | ||
| - Developers of the team have successfully used the IPI to deploy on Packet | ||
| following the documented procedure. | ||
|
|
||
| ## Implementation History | ||
|
|
||
| Significant milestones in the life cycle of a proposal should be tracked in | ||
| `Implementation History`. | ||
|
|
||
| ## Drawbacks | ||
|
|
||
| The IPI implementation is resource-intensive, not just from a development point of view, | ||
| but also for CI, QE, Documentation, and others. | ||
|
|
||
| ## Alternatives | ||
|
|
||
| People not using the IPI workflow can follow the [Packet | ||
| UPI](https://github.com/RedHatSI/openshift-packet-deploy/blob/master/terraform/README.md) | ||
| document. That implies more manual work and the necessary knowledge to identify | ||
| Packet specific parts without any automation help. | ||
|
|
||
| Users may also follow along with the [Deploying OpenShift 4.4 on | ||
| Packet](https://www.openshift.com/blog/deploying-openshift-4.4-on-packet) blog | ||
| post, but there is no automation provided. | ||
|
|
||
| ProjectID is being defined as a high level variable. Arguably, OrganizationID could take this position, as this represents the billing account. OrganizationID is inferred by ProjectID in this proposal. | ||
| With this variation ProjectID could become a required or optional (inherited) property for each cluster. | ||
|
|
||
| ## Infrastructure Needed | ||
|
|
||
| As has been demonstrated in the Packet UPI, users will need access |