Uploaded image for project: 'OpenShift Container Platform (OCP) Strategy'
  1. OpenShift Container Platform (OCP) Strategy
  2. OCPSTRAT-1136

Onboarding New Providers/Platforms (Phase 4)

XMLWordPrintable

    • True
    • False
    • 60% To Do, 20% In Progress, 20% Done
    • 0

      OCP/Telco Definition of Done
      Feature Template descriptions and documentation.
      <--- Cut-n-Paste the entire contents of this description into your new Feature --->
      <--- Remove the descriptive text as appropriate --->

      Feature Overview

      • As RH OpenShift Product Owners, we want to enable new providers/platforms/service with varying levels of capabilities and integration with minimal reliance on OpenShift Engineering.
      • As a new provider/platform partner, I want to enable my solution (hardware and/or software) with OpenShift with minimal effort.

       

      Problem

      • It is currently challenging for us to enable new platforms / providers without taking the heavy burden on doing the platform specific development ourselves.

      Mission

      • We want to enable the long-tail new platforms/providers to expand our reach into new markets and/or support new use cases.
      • We want to remove strict dependencies we have on Engineering teams to review, support and test new providers.
      • We want to lower the effort required for onboarding new platforms/providers.
      • We want to enable new platform/providers to self-certify.
      • We want to define tiered model for provider/platform integration that delineates ownership and responsibilities throughout new provider/platform development lifecycle and support model.
      • We want to reduce time to onboard new provider/platform – ideally to a single release.
      • We want to maintain consistent customer experience across all providers/platforms.

      Goals

      • Expand and fine-tune the OpenShift Validated Cloud & Service Provider (VCSP) program as needed.
      • Expand and fine-tune the OpenShift VCSP conformance testing suite/tool as needed to address new capabilities, new tests, reduce false negatives, and/or reduce errors.
      • Transition ownership to the Cert-Tool team.
      • Enable partners to be able to onboard through self-guided documentation.

      Requirements

      • Step-by-step guide on how to add a new platform/provider for each tier
      • Certification tool for partner to self-certify
      • Certification tool results for (at least) each Y/minor release submitted by partner to Red Hat for acknowledgement
      • DCI program to enable partners to run CI with OpenShift on their platform
      • Well documented, accessible, and up-to-date test suites for providing the test coverage of the partner
      • CI includes upgrade testing of OpenShift with partner's components
      • Partner component upgrade failure should not block OpenShift upgrade
      • Partner code is available in repositories in the openshift org on github with an open source license compatible with OpenShift

       

      Requirement Notes isMvp?
      CI - MUST be running successfully with test automation This is a requirement for ALL features. YES
      Release Technical Enablement Provide necessary release enablement details and documents. YES

      (Optional) Use Cases

      This Section:

      • Main success scenarios - high-level user stories
      • Alternate flow/scenarios - high-level user stories
      • ...

      Questions to answer…

      • ...

      Out of Scope

      Background, and strategic fit

      This Section: What does the person writing code, testing, documenting need to know? What context can be provided to frame this feature.

      Assumptions

      • ...

      Customer Considerations

      • ...

      Documentation Considerations

      Questions to be addressed:

      • What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)?
      • Does this feature have doc impact?
      • New Content, Updates to existing content, Release Note, or No Doc Impact
      • If unsure and no Technical Writer is available, please contact Content Strategy.
      • What concepts do customers need to understand to be successful in [action]?
      • How do we expect customers will use the feature? For what purpose(s)?
      • What reference material might a customer want/need to complete [action]?
      • Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available.
      • What is the doc impact (New Content, Updates to existing content, or Release Note)?

       

      References

            julim Ju Lim
            julim Ju Lim
            Dennis Gilmore, Doug Hellmann, Joel Speed, Marco Braga, Marcos Entenza Garcia, Michael McCune, Richard Vanderpool
            Marco Braga Marco Braga
            Jianwei Hou Jianwei Hou
            Stephanie Stout Stephanie Stout
            Michael McCune Michael McCune
            Eric Rich Eric Rich
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: