Epic Goal

• add support for connection to a to be managed cluster through a different route than the default one
• we need to allow the customization of which IP / hostname the remote cluster would use, but also which IP of the remote cluster ACM would use

Why is this important?

• in this case, the default route would go through a firewall that would drop the connection. Other ips are available but would require to set something akin to an hostalias to the cluster
• The customer in that usecase seem to be using load balancers before clusters and configure them to reject connections from the internal network. communication is expected to go through a different route.

Scenarios

• for one reason or another the public record used for the cluster shouldn't be used by ACM to access the cluster but another route can be used
• one example of this would be that a load balancer is used and connections should be established without using the DNS records that would point to the LB instead of other IPs of the cluster that should be used for management of it.
• The customer wanted to initially use ACM behind a load balancer but it seems since they want to use them for both managed cluster and ACM.

Acceptance Criteria

• it would be possible to override default dns resolution for the ACM pods.

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. https://issues.redhat.com/browse/RFE-1797 - it seems forwarding to another DNS is the only way forward as editing coreDNS is not accepted.

Open questions:

1. Would it be feasible to set up a DNS that would be managed by ACM and used for this in the scenario where managed clusters need to connect through a different IP to ACM or ACM needs to connect to managed cluster through alternative IPs or should we expect the customer to setup and managed another DNS for this instead
2. should we concentrate only on the option of setting up dns forwarding so that a custom dns can be used for resolution in both scenarios (override in a managed cluster, override in ACM hub itself)

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>