Uploaded image for project: 'OpenShift Hive'
  1. OpenShift Hive
  2. HIVE-1812

post-merge testing: Support external DNS for OpenShift on GCP

XMLWordPrintable

    • Support external DNS for OpenShift on Cloud Providers
    • BU Product Work
    • False
    • None
    • False
    • Not Selected
    • To Do
    • OCPSTRAT-990 - [GA] Allow customer managed DNS solutions for GCP: Implementation
    • OCPSTRAT-990[GA] Allow customer managed DNS solutions for GCP: Implementation
    • 100% To Do, 0% In Progress, 0% Done
    • S
    • Hide

      4/16: Still wait for https://issues.redhat.com/browse/OCPBUGS-29067 and its backporting to 4.15.z

      5/6: Still wait for https://issues.redhat.com/browse/OCPBUGS-29067 and its backporting to 4.15.z

      Show
      4/16: Still wait for  https://issues.redhat.com/browse/OCPBUGS-29067  and its backporting to 4.15.z 5/6: Still wait for  https://issues.redhat.com/browse/OCPBUGS-29067  and its backporting to 4.15.z

      TL;DR

      Hive API changes: None.
      Hive doc changes: Document that this feature is mutually exclusive with Managed DNS.

      • Per enhancement the necessary logic will be contained within installer/OCP, activated via an install-config knob.
      • Enablement via hive will comprise using that knob in the install-config passed via ClusterDeployment.Spec.Provisioning.InstallConfigSecretRef, which is opaque to hive.
      • OSD: Enablement will comprise adding a knob to the UI which will flip the install-config switch and disable hive's managed DNS.

      Epic Goal

      • As an administrator, I would like to deploy OpenShift 4 clusters to supported cloud providers leveraging my custom DNS service.
      • Enable customers to deploy full stack automated OpenShift on different cloud providers using their own DNS service instead of the cloud provider's DNS solution (AWS Route 53, Google Cloud DNS, etc.)

      Why is this important?

      • Provides customers with the flexibility to leverage their own custom managed ingress DNS solutions already in use within their organizations. 
      • Required for regions like AWS GovCloud in which many customers may not be able to use the Route53 service (only for commercial customers) for both internal or ingress DNS.
      • OpenShift managed internal DNS solution insures cluster operation and nothing breaks during updates.

      Scenarios

      1. ...

      Acceptance Criteria

      • Customers need the ability to dynamically control DNS records of an external DNS server via Kubernetes resources in a DNS provider-agnostic way.
      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      1. The External DNS Operator available via OperatorHub, has been in Tech Preview since OpenShift 4.8. 
      2. DNS work for KNI
      3. Prerequisite for the internal clusters epic

      Open questions::

      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>

              efried.openshift Eric Fried
              mworthin@redhat.com Mike Worthington
              Jianping Shu Jianping Shu
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated: