Uploaded image for project: 'OpenStack Strategy'
  1. OpenStack Strategy
  2. RHOSSTRAT-1130

Make Generally Available OpenShift IPv4/v6 dual-stack on OpenStack IPv6 single-stack

XMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • OpenShift
    • None
    • Moderate
    • Not Selected
    • False
    • False
    • Hide

      None

      Show
      None
    • 0
    • 0
    • rhos-conplat-osasinfra
    • Red Hat OpenStack Services on OpenShift (formerly Red Hat OpenStack Platform)
    • Enhancement

      Feature Overview

      Provide OpenShift dual-stack deployments on OpenStack RHOSP 17.1 IPv6 single-stack environments as a generally available feature.

      Background and Strategic Fit

      Implementation of the described architecture currently requires a support exception and it is desired that the architecture becomes a standard available configuration.

      Goals

      • Perform testing to validate the scenario of a dual-stack OpenShift (versions 4.18 and 4.20) deployment on single-stack IPv6 OpenStack RHOSP 17.1 environment.
        • If issues are identified that would not permit this to become generally available, or there are architecture decisions that should be noted and documented to provide this as a viable deployment, those need to be identified as part of the testing.
      • Implement automated testing to validate continued availability of this architecture deployment and identify any regressions early.
      • Update OpenShift (Shift on Stack) documentation that indicates this architecture deployment is now available for use generally.

      Requirements
      A list of specific needs, capabilities, or objectives that a Feature must deliver to satisfy the Feature. Some requirements will be flagged as MVP. If an MVP gets shifted, the Feature shifts. If a non MVP requirement slips, it does not shift the feature.

      Requirement Notes isMVP?
      Initial validation that the desired architecture is functionally complete and usable. It is expected the feature is a test-only validation and that net-new development is not necessary. YES
      Implement automated testing that covers the now generally available architecture. Automated testing is expected for any generally available feature to identify regressions early and continued validation it continues to operate nominally. YES
      Documentation updates describing the supported architecture and identifying it as generally available. Update the appropriate documentation indicating that the described architecture is valid for deployment without support exception. YES

       

      Done - Acceptance Criteria

      • all testing has been performed and in the positive
      • automated testing has been implemented and configured to execute periodically (particularly prior to release of new major releases)
      • documentation has been updated indicating support for desired architecture

      Use Cases - i.e. User Experience & Workflow

      • provides functionality to CNFs that require IPv4 network connectivity even though the base infrastructure if IPv6 only
        • there is no expectation that fast-data path is included in this testing effort

      Out of Scope

      • backporting of the functionality to prior releases; all work should be available in the latest release of both OSP and OCP
      • ability to convert a dual-stack OpenStack environment to single-stack
      • testing of fast-data path infrastructure

      Documentation Considerations

      • update to existing documentation indicating the architecture in question is available for deployment
        • also release notes where applicable should indicate this architecture is now generally available
      • if there are specific implementation details required for this architecture deployment the documentation should guide the administrator towards a successful deployment
      • removal of any notes indicating the architecture is not supported or is technical preview

      Questions to Answer

      • what is the currently supported version matrix between OpenShift and OpenStack where this architecture is first available?
        • OpenStack 17.1 with OpenShift 4.18 and 4.20
      • how often should automated testing be performed and in which system will perform the validation going forward?
      • can the OpenStack 17.1 infrastructure being deployed managed both 4.18 and 4.20 deployments of OpenShift at the same time to save time?

       

      Customer Considerations

      • None at this time

              lmadsen@redhat.com Leif Madsen
              lmadsen@redhat.com Leif Madsen
              Itay Matza, Tushar Jadhav
              Gil Rosenberg Gil Rosenberg
              rhos-conplat-osasinfra
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: