Uploaded image for project: 'OpenShift API Server'
  1. OpenShift API Server
  2. API-1433

Complete Route API compatibility

XMLWordPrintable

    • uShift Sprint 225, uShift Sprint 226, uShift Sprint 227, uShift Sprint 228

      Validation and defaulting (specifically, spec.host assignment) has historically been implemented as code inside openshift-apiserver, operating on types that must remain internal to openshift-apiserver.

      MicroShift does not include openshift-apiserver, and can not depend on openshift-apiserver, so it is serving the Route API using a CRD. CRs are handled by the CR handler inside kube-apiserver.

      In order to have identical validation and defaulting behaviors, the existing code inside openshift-apiserver must be refactored so that it can be extracted and reused without taking a dependency on openshift-apiserver. In concrete terms, this means that the existing code will be modified to operate on the user-facing route/v1 types (whose source of truth is openshift/api) and moved to a library. The openshift-apiserver will maintain shims that convert from the internal "hub" route types to v1, invoke the extracted library behavior, and convert back from v1 to internal types. Separately, an admission plugin will be added to kube-apiserver via the fork in openshift/kubernetes, and it will handle v1 routes by sharing the same library code used by openshift-apiserver. No active integration work should be required within openshift/microshift beyond its usual OCP rebase.

            bluddy Ben Luddy
            mfojtik@redhat.com Michal Fojtik
            David Eads
            Rahul Gangwar Rahul Gangwar
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: