Uploaded image for project: 'OpenShift Windows Containers'
  1. OpenShift Windows Containers
  2. WINC-802

Windows Node Proxy Configuration

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Major Major
    • WMCO 9.0.0
    • None
    • None
    • None
    • Node Proxy
    • False
    • None
    • False
    • Green
    • Done
    • OCPSTRAT-292 - Support cluster-wide proxy on Windows Containers
    • OCPSTRAT-292Support cluster-wide proxy on Windows Containers
    • 100
    • 100% 100%

      Epic Goal

      • The goal of this epic is to allow Windows nodes to consume and use global egress proxy configuration
        when making external requests outside the cluster's internal network. Windows worker nodes do not currently consume or respect cluster-wide proxy settings like other OpenShift components including Linux worker nodes. This effort will work to plug feature disparity by making the Windows Machine Config Operator (WMCO) aware of cluster proxy settings at install time and reactive during runtime.

      Why is this important?

      • This work needed to expand the Windows containers production use case, enabling users to add Windows nodes and run workloads easily and successfully in a proxy-enabled cluster. This is an extremely important ask for customer environments where Windows nodes need to pull images from registries secured behind the client's proxy server or make requests to off-cluster services, and those that use a
        custom public key infrastructure.

      Scenarios

      There are 3 different workflows that affect the cluster-wide proxy use case.

      1. A cluster creator specifies global proxy settings at install time
      2. A cluster administrator introduces new global proxy settings during runtime in a proxy-less cluster
      3. A cluster administrator changes or removes existing global proxy settings during cluster runtime

      The first scenario would occur through their install-config.yaml. The latter 2 scenarios occur through changing the Proxy object named cluster or by modifying certificates present in their trustedCA ConfigMap.

      In all cases, Windows nodes can be joined to the cluster after altering proxy settings, which would result in WMCO applying proxy settings during initial node configuration. In the latter 2 scenarios, Windows nodes may already exist in the cluster, in which case WMCO will react to the changes by updating the state of each instance.

      Acceptance Criteria

      • WMCO sets proxy settings on Windows nodes. Both:
      • WMCO reacts to changes to the cluster-wide proxy settings and updates Windows nodes proxy settings in response
      • Maintain normal functionality in non-proxied clusters
      • CI - MUST be running successfully with tests automated
        • new job in WMCO repo to test cluster-wide proxy on vSphere
      • Release Technical Enablement - Provide necessary release enablement details and documents.

      Dependencies (internal and external)

      • There already exists a protocol for publishing global egress proxy throughout the cluster, owned by the network edge team. CNO and OLM consume the Proxy settings and WMCO will rely on them as well.

      Previous Work / Helpful links / Guides:

      Open questions:

      N/A

      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>

            mohashai Mohammad Shaikh
            rteague@redhat.com Russell Teague
            Aharon Rasouli Aharon Rasouli
            Votes:
            3 Vote for this issue
            Watchers:
            12 Start watching this issue

              Created:
              Updated:
              Resolved: