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

Complete Route API compatibility

XMLWordPrintable

    • Strategic Portfolio Work
    • False
    • None
    • False
    • OCPSTRAT-598 - Initial Dev Preview version of MicroShift
    • High
    • 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 (Inactive)
              David Eads
              Rahul Gangwar Rahul Gangwar
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: