OCP/Telco Definition of Done
Epic Template descriptions and documentation.

<--- Cut-n-Paste the entire contents of this description into your new Epic --->

Background

Feature Goal: Support OpenShift installation in AWS Shared VPC scenario where AWS infrastructure resources (at least the Private Hosted Zone) belong to an account separate from the cluster installation target account.

The External DNS Operator is impacted by OCPBU-558 because the current API doesn't expose an optional AWS Role ARN field, so there isn't a supported way to use the External DNS Operator to create Route53 records in another account within a Shared VPC.

Luckily, the External DNS code already supports the --aws-assume-role argument, which uses the specified AWS Role ARN when creating new DNS records. This argument directly solves the need to use a different AWS Role Arn with Shared VPC clusters.

Epic Goal

• Understand External DNS and External DNS Operator's capability of using a pre-existing Route53 inside Shared VPC Clusters for private hosted zones
• Add support to External DNS or the External DNS Operator for using pre-existing Route53 for private hosted zones
• Add E2E CI jobs for testing new Shared VPC support

Note: This epic does NOT add AWS Security Token Service (STS) support to the ExternalDNS Operator. Currently, ExternalDNS Operator does not support STS.

Why is this important?

• Currently, OpenShift users are unable to create DNS records with External DNS Operator in a pre-existing Route53 private hosted zone which means OpenShift users can't share the Route53 component with a Shared VPC
• Shared VPCs are considers AWS best practice

Scenarios

1. ...

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• The capabilities of the External DNS Operator are understood and documented when providing functionality for OCPBU-558
• Users using External DNS Operator are able to create DNS records inside a pre-existing Route53 private hosted zone in a Shared VPC AWS cluster

Dependencies (internal and external)

1. Installer Team is adding the new API fields required for enabling sharing Route53 with in Shared VPCs in https://issues.redhat.com/browse/CORS-2613
2. Testing this epic requires having access to two AWS account
3. External DNS Operator can provide DNS records on behalf of AWS Load Balancer Operator

Previous Work (Optional):

1. Questions were raised about External DNS here: https://redhat-internal.slack.com/archives/C054PJX8LE8/p1684417445929929?thread_ts=1684242798.818099&cid=C054PJX8LE8 
2. Slack channel #tmp-xcmbu-114

AWS Load Balancer Operator (ALBO) Relationship

Though the Shared VPC requirements don't directly impact AWS Load Balancer Operator, External DNS is marketed as a solution to creating DNS Records for ALBO with use of service and ingress types.

At the moment, OpenShift's External DNS Operator only supports creating DNS records for routes and service-types objects, not ingress-type objects (see https://issues.redhat.com/browse/RFE-3925). Furthermore, ALBO only officially support creating NLBs for Ingress-types. Therefore, currently there are no supported touch points between ALBO and External DNS Operator, but this relationship may change in the future.

Regardless, Shared VPC has no direct impact on ALBO.

Open questions:

1. Have we tested External DNS functionality in ROSA? What about ROSA with AWS STS mode? 
2. Should we document external-dns-operator's interactions with Shared VPC clusters in the README of the project?
3. Should the External DNS be documented in the same enhancement https://github.com/openshift/enhancements/pull/1397? : Yes
4. If External DNS should support using a different Route53 account in an AWS Shared VPC, does the --aws-assume-role argument provide what we are looking for?: Yes
5. Does this impact ALBO? ALBO doesn't create DNS records, but instead users can use external-dns to create DNS records for them. Does that impact the need for supporting External DNS for this effort?: No

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>