Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-16089

Using appsDomain recreating canary route can lead to an degraded ingress operator

    XMLWordPrintable

Details

    • Moderate
    • No
    • Sprint 239, Sprint 240, Sprint 241, Sprint 242
    • 4
    • Rejected
    • False
    • Hide

      None

      Show
      None
    • Hide
      Previously, the Ingress Operator created its canary route without specifying the `spec.subdomain` or the `spec.host` parameter on the route. Usually, this caused the API server to use the cluster's Ingress domain, which matches the domain of the default Ingress Controller, to set a default value for the `spec.host` parameter. However, if you configured the cluster by using the `appsDomain` option to set an alternative Ingress domain, the route host would have the alternative domain. Further, if you deleted the canary route, the route would be recreated with a domain that did not match the default Ingress Controller's domain, which would cause canary checks to fail. Now, the Ingress Controller specifies the `spec.subdomain` parameter when it creates the canary route. If you use the `appsDomain` option to configure your cluster and then delete the canary route, the canary checks do not fail. (link:https://issues.redhat.com/browse/OCPBUGS-16089[*OCPBUGS-16089*])
      Show
      Previously, the Ingress Operator created its canary route without specifying the `spec.subdomain` or the `spec.host` parameter on the route. Usually, this caused the API server to use the cluster's Ingress domain, which matches the domain of the default Ingress Controller, to set a default value for the `spec.host` parameter. However, if you configured the cluster by using the `appsDomain` option to set an alternative Ingress domain, the route host would have the alternative domain. Further, if you deleted the canary route, the route would be recreated with a domain that did not match the default Ingress Controller's domain, which would cause canary checks to fail. Now, the Ingress Controller specifies the `spec.subdomain` parameter when it creates the canary route. If you use the `appsDomain` option to configure your cluster and then delete the canary route, the canary checks do not fail. (link: https://issues.redhat.com/browse/OCPBUGS-16089 [* OCPBUGS-16089 *])
    • Bug Fix
    • Done

    Description

      Description of problem:

      In case the [appsDomain|https://docs.openshift.com/container-platform/4.13/networking/ingress-operator.html#nw-ingress-configuring-application-domain_configuring-ingress] is specified and a cluster-admin is deleting accidentally all routes on a cluster, the route canary in the namespace openshift-ingress-canary is created with the domain specified in the .spec.appsDomain instead of .spec.domain of the definition in Ingress.config.openshift.io.

Additionally the docs are a bit confusing. On one page (https://docs.openshift.com/container-platform/4.13/networking/ingress-operator.html#nw-ingress-configuring-application-domain_configuring-ingress) it's defined as 

{code:none}
As a cluster administrator, you can specify an alternative to the default cluster domain for user-created routes by configuring the appsDomain field. The appsDomain field is an optional domain for OpenShift Container Platform to use instead of the default, which is specified in the domain field. If you specify an alternative domain, it overrides the default cluster domain for the purpose of determining the default host for a new route.

For example, you can use the DNS domain for your company as the default domain for routes and ingresses for applications running on your cluster.

      In the API spec (https://docs.openshift.com/container-platform/4.11/rest_api/config_apis/ingress-config-openshift-io-v1.html#spec) the correct behaviour is explained

      appsDomain is an optional domain to use instead of the one specified in the domain field when a Route is created without specifying an explicit host. If appsDomain is nonempty, this value is used to generate default host values for Route. Unlike domain, appsDomain may be modified after installation. This assumes a new ingresscontroller has been setup with a wildcard certificate.

      It would be nice if the wording could be adjusted as `you can specify an alternative to the default cluster domain for user-created routes by configuring` does not fits good as more or less all new created routes (operator created and so on) getting created with the appsDomain.

      Version-Release number of selected component (if applicable):{code:none}
OpenShift 4.12.22

      How reproducible:

      see steps below

      Steps to Reproduce:

      1. Install OpenShift
2. define .spec.appsDomain in Ingress.config.openshift.io
3. oc delete route canary -n openshift-ingress-canary
4. wait some seconds to get the route recreated and check cluster-operator

      Actual results:

      Ingress Operator degraded and route recreated with wrong domain (.spec.appsDomain)

      Expected results:

      Ingress Operator not degraded and route recreated with the correct domain (.spec.domain)

      Additional info:

      Please see screenshot

      Attachments

        Issue Links

          relates to

          Bug - A problem that impairs or prevents the functions of the product. OCPBUGS-32887 OCP upgrade from 4.13 to 4.14 triggers the error "failed to update canary route openshift-ingress-canary/canary"

          • Normal - To be worked after urgent and high priorities are resolved. This term is chosen when the severity of an issue is relatively close to the level of effort to fix it. The existence of an easily implemented workaround can also lead to this priority level instead of a higher priority.
          • POST
          links to

          GitHub openshift/cluster-ingress-operator#965: OCPBUGS-16089: Set spec.subdomain on the canary route

          Web Link RHEA-2023:5006 rpm

          Activity

            People

              mmasters1@redhat.com Miciah Masters
              rhn-support-anowak Andreas Nowak
              Melvin Joseph Melvin Joseph
              Darragh Fitzmaurice Darragh Fitzmaurice
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: