Uploaded image for project: 'OpenStack as Infra'
  1. OpenStack as Infra
  2. OSASINFRA-3007

EgressIP support for OpenStack - CloudPrivateIPConfig Mover interface

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Normal Normal
    • openshift-4.13
    • openshift-4.13
    • None
    • None
    • EgressIP support for OpenStack - CloudPrivateIPConfig Mover interface
    • False
    • None
    • False
    • Not Selected
    • Done
    • OCPSTRAT-400 - EgressIP support for OpenStack - CloudPrivateIPConfig Mover interface
    • 100
    • 100% 100%
    • S

      *{}Adding Feature wrapper to this work Epic based on new release tracking criteria{}*

      Goal

      We want to maintain EgressIP FIP association when EgressIP gets moved to another node e.g. in case of a failover. In order to do so we need a new interface added in addition to `CloudPrivateIPConfig`, that will be called in such situation. This will allow OpenStack implementation to just change the port association without deleting it and recreating and losing the FIP association that user may have added.

      Why is this important?

      Without this users that will attach FIPs to the EgressIP ports will need to maintain that manually in case of failovers. That obviously doesn't scale. Please note that FIP association is essential for users when they want a consistent egress IP address routed outside of the OpenShift cluster router.

      Scenarios

      1. Main scenario to support here is to be able to assign FIP to an EgressIP port and then for that association to survive an EgressIP failover and rescheduling to another node. This can be simulated by rebooting the node or changing the association on the CloudPrivateIPConfig CRD.

      Acceptance Criteria

      • We should develop a test simulating the failover. The proper place is the openstack-test suite, as test is openstack-specific.
      • Release Technical Enablement
      • Information about limitation removed from the docs

      Dependencies (internal and external)

      1. We need SDN team support if Mover interface is also implemented by any other platform.

      Previous Work (Optional):

      1. https://issues.redhat.com/browse/SDN-3027
      2. Limitation is documented: https://issues.redhat.com/browse/SDN-3191
      3. This (unmerged!) commit implements most of the code: https://github.com/dulek/cloud-network-config-controller/commit/528ed6d13a7eb1e9e05b74f693df5b85c7e15a70

      Open questions::

      1. Can other platforms benefit from this?

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Technical 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>

        1.
        Docs Tracker Sub-task Closed Undefined Unassigned
        2.
        PX Tracker Sub-task Closed Undefined Unassigned
        3.
        QE Tracker Sub-task Closed Undefined Jon Uriarte
        4.
        TE Tracker Sub-task Closed Undefined Unassigned

            mdulko Michał Dulko
            akaris@redhat.com Andreas Karis
            Ramón Lobillo Ramón Lobillo
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: