• Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • None
    • ACS-CS use External DNS
    • Future Sustainability
    • False
    • Hide

      None

      Show
      None
    • True
    • Not Selected
    • In Progress
    • ROX-26332 - ACS Cloud Service 2026 Run the business
    • 9% To Do, 9% In Progress, 82% Done
    • Hide

      Oct 7

      Agreed with the team to go with the "hacky" solution, which is to install ExternalDNS CR from the dev scripts. Fighting with CI and Konflux. 

      Sep 30

      Adjusting the e2e/gitops setup to leverage the Openshift "infrastructure" CR - which gives us a unique name for running e2e tests (w.r.t. external-dns)

      Sep 23:

      Refactoring E2E test setup. Some unexpected complexity arose with conflicting external-dns instances during e2e tests. 

      Sep 16: No progress, PTO

      Sep 2: ** Fixing some failing e2e tests after removing Route53.    * ROX-30638{{}}{*}

      Aug 26: Removing all traces of old Route53 code in progress (ROX-30638

      Aug 19

      • Rollout to production completed. Started to clean up old Route53 code. 

      Aug 12

      • Rollout to production in progress. Canary and soak group are using external-dns. Rollout to rest in progress. Using AI companion to help verifying connectivity. 

      July 22

      • Rollout to stage
      • Prod rollout delayed by waiting for Openshift 4.17

      July 15

      • Rollout to integration today

      July 8

      • There was a bug in the openhift ingress controller that would not update the route labels when the ingress labels were updated. This prevented us from enabling the external-dns in "canary" mode. 
        • acscs-manifests was moved from using an Ingress to an Openshift route to fix this.
      • Successfully migrated a tenant on integration to use external dns, end-to-end. The routes were created, and deleted with the tenant. 
      • Working on a script to perform migration. TXT records need to be created so that external-dns assumes ownership of the existing CNAME records.

      July 1

      • No progress, PTO

      June 17

      • Continuing implementation, we are moving to Openshift 4.17.

      June 10

      • I need to pivot away from using the operator to install external-dns. Some features are only available in Openshift 4.17, and we are running 4.16.

      June 3

      May 27

      May 20

      • Started installing External-DNS on integration
      Show
      Oct 7 Agreed with the team to go with the "hacky" solution, which is to install ExternalDNS CR from the dev scripts. Fighting with CI and Konflux.  Sep 30 Adjusting the e2e/gitops setup to leverage the Openshift "infrastructure" CR - which gives us a unique name for running e2e tests (w.r.t. external-dns) Sep 23: Refactoring E2E test setup. Some unexpected complexity arose with conflicting external-dns instances during e2e tests.  Sep 16: No progress, PTO Sep 2: ** Fixing some failing e2e tests after removing Route53.    *   ROX-30638 {{}}{*} Aug 26: Removing all traces of old Route53 code in progress ( ROX-30638 )  Aug 19 Rollout to production completed. Started to clean up old Route53 code.  Aug 12 Rollout to production in progress. Canary and soak group are using external-dns. Rollout to rest in progress. Using AI companion to help verifying connectivity.  July 22 Rollout to stage Prod rollout delayed by waiting for Openshift 4.17 July 15 Rollout to integration today July 8 There was a bug in the openhift ingress controller that would not update the route labels when the ingress labels were updated. This prevented us from enabling the external-dns in "canary" mode.  acscs-manifests was moved from using an Ingress to an Openshift route to fix this. Successfully migrated a tenant on integration to use external dns, end-to-end. The routes were created, and deleted with the tenant.  Working on a script to perform migration. TXT records need to be created so that external-dns assumes ownership of the existing CNAME records. July 1 No progress, PTO June 17 Continuing implementation, we are moving to Openshift 4.17. June 10 I need to pivot away from using the operator to install external-dns. Some features are only available in Openshift 4.17, and we are running 4.16. June 3 ROX-29373 in review Starting ROX-29589     May 27 Continuing ROX-29373 May 20 Started installing External-DNS on integration

      Openshift ships the external-dns operator.  It allows to

      • By annotating a route, create a DNS entry in some DNS zone

      This would be great, because we have lots of code on fleetshard sync to do that. It would be great to offload it to external-dns, and remove a significant chunk of logic, and not have to maintain it. 

      This could perhaps even significantly simplify moving a tenant from a cluster to another. 

      To remember:

      • External-DNS records have a concept of "DNS Record Ownership". When you deploy external-dns, you give it some "unique identifier". When creating records, External-DNS will add a sibling TXT record to identity that it "owns" the record. This is to prevent competing external-dns instances that operate on the same DNS zone.

              rh-ee-lcleroux Ludovic Cleroux
              rh-ee-lcleroux Ludovic Cleroux
              ACS Cloud Service
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: