|
| 1 | +--- |
| 2 | +title: Networking for ROSA HCP |
| 3 | +authors: |
| 4 | + - "@mzazrivec" |
| 5 | +reviewers: |
| 6 | + - |
| 7 | +creation-date: 2025-02-24 |
| 8 | +last-updated: 2025-03-10 |
| 9 | +status: provisional |
| 10 | +--- |
| 11 | + |
| 12 | +# Networking for ROSA HCP |
| 13 | + |
| 14 | +## Table of Contents |
| 15 | + |
| 16 | +<!-- START doctoc generated TOC please keep comment here to allow auto update --> |
| 17 | +<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> |
| 18 | + |
| 19 | +- [Glossary](#glossary) |
| 20 | +- [Summary](#summary) |
| 21 | +- [Motivation](#motivation) |
| 22 | + - [Goals](#goals) |
| 23 | + - [Non-Goals/Future Work](#non-goalsfuture-work) |
| 24 | +- [Proposal](#proposal) |
| 25 | + - [User Stories](#user-stories) |
| 26 | + - [Functional Requirements](#functional-requirements) |
| 27 | +- [Alternatives](#alternatives) |
| 28 | +- [Upgrade Strategy](#upgrade-strategy) |
| 29 | +- [Implementation History](#implementation-history) |
| 30 | + |
| 31 | +<!-- END doctoc generated TOC please keep comment here to allow auto update --> |
| 32 | + |
| 33 | +## Glossary |
| 34 | + |
| 35 | +Refer to the [Cluster API Book Glossary](https://cluster-api.sigs.k8s.io/reference/glossary.html). |
| 36 | + |
| 37 | +## Summary |
| 38 | + |
| 39 | +This proposal defines implementation of networking infrastructure in CAPA for ROSA Hosted Control Plane. |
| 40 | + |
| 41 | +## Motivation |
| 42 | + |
| 43 | +To be able to provision a new ROSA HCP kubernetes cluster using CAPA, one has to create and setup the underlying network infrastructure first: VPC, public and private subnets, internet gateway, routing tables for both subnets, elastic IP address. |
| 44 | + |
| 45 | +All of the above can be currently provisioned and configured via AWS CLI, AWS Management Console or Terraform. Motivation for this work is to be able to provision and configure the network infrastructure for ROSA HCP using CAPI. |
| 46 | + |
| 47 | +### Goals |
| 48 | + |
| 49 | +1. Implement a new custom resource `RosaNetwork` representing the networking stack for ROSA HCP. |
| 50 | +2. It will be possible to reference the new `RosaNetwork` resource from ROSA control plane resource |
| 51 | +3. Implement standard CRUD for the new `RosaNetwork` resource. |
| 52 | +4. Support the same networking scenarios as [ROSA CLI](https://github.com/openshift/rosa) using the same embeded AWS CloudFormation template that ROSA CLI uses. |
| 53 | + |
| 54 | +### Non-Goals/Future Work |
| 55 | + |
| 56 | +- Modify current networking code in AWS / EKS clusters. |
| 57 | +- Support custom CloudFormation template. |
| 58 | + |
| 59 | +## Proposal |
| 60 | + |
| 61 | +The goal of this proposal is to be able to provision the networking infrastructure required for a ROSA HCP cluster. |
| 62 | + |
| 63 | +[ROSA CLI](https://github.com/openshift/rosa) supports creation of the networking infrastructure for ROSA HCP and uses [AWS CloudFormation](https://aws.amazon.com/cloudformation/) template under the hood. The [CloudFormation template used by ROSA CLI](https://github.com/openshift/rosa/blob/master/cmd/create/network/templates/rosa-quickstart-default-vpc/cloudformation.yaml) allows to specify four parameters: CloudFormation stack name, AZ count (between 1 and 3), region and CIDR block for the VPC. The created CloudFormation stack then contains a VPC, public and private subnets (each pair created in separate AZ), internet gateway attached to VPC, elastic IPs, NAT gateways, public and private routing tables and a security group. |
| 64 | + |
| 65 | +Adopting the CloudFormation template used by rosa-cli would mean that CAPA and the `RosaNetwork` custom resource would be relying on a mechanism that is know to work well and any changes or fixes implemented in ROSA CLI would be picked up automatically in CAPA. |
| 66 | + |
| 67 | +In practical terms, implementation of the proposal would mean: |
| 68 | +1. A new custom resource definition `RosaNetwork` in CAPA |
| 69 | +2. A new reconciler for the new custom resource, implementing CRUD. |
| 70 | +3. Modifications in the ROSA control plane CRD & reconciler so that it would be possible to reference the `RosaNetwork` resource from control plane. |
| 71 | +4. New tests. |
| 72 | + |
| 73 | +### User Stories |
| 74 | + |
| 75 | +1. As a CAPA user, I want to be able to provision the network infrastructure for ROSA HCP. |
| 76 | +2. As a CAPA user, I want to be able to use the provisioned network infrastructure in ROSA HCP control plane. |
| 77 | +3. As a CAPA user, I want to be able to modify the network inrastructure previously provisioned by CAPA. |
| 78 | +4. As a CAPA user, I want to be able to delete the network infrastcture previously provisioned by CAPA. |
| 79 | + |
| 80 | +#### Functional Requirements |
| 81 | + |
| 82 | +1. Ability to create a new custom resource `RosaNetwork` with four attributes: name, AZ count, region and CIDR block for VPC. |
| 83 | +2. Reconciler implementing CRUD for the `RosaNetwork` resource. |
| 84 | +3. Ability to reference the new custom resource from ROSA HCP control plane. |
| 85 | + |
| 86 | +## Alternatives |
| 87 | + |
| 88 | +1. Implement CRDs and reconcilers for each of the atoms of network infrastructure (VPCs, subnets, etc.). |
| 89 | +2. Implement the network infrasructure similar to EKS, the network parameters being attributes of the EKS control plane. |
| 90 | +3. Not implement anything and rely purely on AWS CLI or Terraform. |
| 91 | + |
| 92 | +## Upgrade Strategy |
| 93 | + |
| 94 | +The implementation will not affect CAPA upgrades. |
| 95 | + |
| 96 | +## Implementation History |
| 97 | + |
| 98 | +- [ ] 2025-03-17: Proposed idea in an issue or [community meeting] |
| 99 | + |
| 100 | +<!-- Links --> |
| 101 | +[community meeting]: https://docs.google.com/document/d/1ushaVqAKYnZ2VN_aa3GyKlS4kEd6bSug13xaXOakAQI/edit#heading=h.pxsq37pzkbdq |
0 commit comments