Uploaded image for project: 'OpenShift Specialist Platform Team'
  1. OpenShift Specialist Platform Team
  2. SPLAT-1126

Add support to the Installer to specify a custom MTU for the cluster network

    • Add support to the Installer to specify a custom MTU for the cluster network
    • Strategic Product Work
    • Hide
      Nov 28th:
      - 46013 merged
      - installer team approved the 7765
      - waiting jobs be available in 7765 to trigger the test

      Nov 28th: changes in place. PRs waiting for review:
      - https://github.com/openshift/installer/pull/7765
      - https://github.com/openshift/release/pull/46013
      Show
      Nov 28th: - 46013 merged - installer team approved the 7765 - waiting jobs be available in 7765 to trigger the test Nov 28th: changes in place. PRs waiting for review: - https://github.com/openshift/installer/pull/7765 - https://github.com/openshift/release/pull/46013
    • False
    • Green
    • To Do
    • OCPSTRAT-695 - Add support to the Installer to specify a custom MTU for the cluster network
    • OCPSTRAT-695Add support to the Installer to specify a custom MTU for the cluster network
    • 0% To Do, 0% In Progress, 100% Done

      Epic Goal

      • As a user, I need to be able to provide a custom MTU to be consumed by the OpenShift Installer so I can change the cluster network MTU on day-0

      Why is this important?

      • Customers who are running OpenShift on environments where the network traffic between the cluster and external endpoints is limited to a certain MTU. Some examples are OpenShift clusters running on public clouds like AWS, Azure or GCP where these clusters are connected to external services running on the customer premises via direct links, VPNs, etc... and limited to a certain MTU

      Scenarios

      1. The OpenShift Installer will accept another parameter through the install-config manifest that will be used as an option to change the default MTU value for the cluster network

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.

      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>

              rhn-support-mrbraga Marco Braga
              mak.redhat.com Marcos Entenza Garcia
              Yunfei Jiang Yunfei Jiang
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: