Uploaded image for project: 'Network Edge'
  1. Network Edge
  2. NE-674

[CFE] Expose port configuration to the ingress operator

XMLWordPrintable

    • ingress-port-config
    • False
    • False
    • Green
    • To Do
    • Impediment
    • 0% To Do, 0% In Progress, 100% Done
    • Undefined
    • Hide

      CFE driven Epic.

        

      Show
      CFE driven Epic.   
    • 0
    • 0

      OCP/Telco Definition of Done
      Epic Template descriptions and documentation.

      Epic Goal

      • Expose port configuration options for the ingress operator through the configuration API

      Why is this important?

      • In order to run multiple `router` on the same physical machine, it is required to change the listening port for the specific `router` via ingress Operator. Running multiple `router` on the same Node is found to be cost efficient, allows scaling of `router` without adding more Node(s) and also makes the use case with `router` sharding easier.

      Scenarios

      1. Cost efficiency: ability to run multiple ingress controllers on the same infrastructure (node/s)
      2. Simplified sharding: no need for the dedicated infrastructure (node/s) for each new shard
      3. Parity with OCP 3.x where it was possible set the ports (ROUTER_SERVICE_HTTP(S)_PORT variable)

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • Documentation - Provide necessary documentation details
      • Administrator can configure which port they'd like to bind to on the node

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      1. https://github.com/openshift/api/pull/965
      2. https://github.com/openshift/cluster-ingress-operator/pull/634
      3. https://github.com/openshift/enhancements/pull/855

      Open questions/Concerns:

      1. All eggs into one basket. Infrastructure failures may impact more than one (all) ingress controller as there is no "natural" barrier in the form of the port collision
      2. Non-host network publishing strategies are preferred alternatives

      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>

              luzuccar@redhat.com Luigi Mario Zuccarelli
              pweil@redhat.com Paul Weil (Inactive)
              Arvind Iyengar Arvind Iyengar (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: