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

Deliver Lightspeed with a separate operator

XMLWordPrintable

    • Not Selected
    • False
    • False
    • Hide

      None

      Show
      None
    • 0
    • 0
    • 33% To Do, 67% In Progress, 0% Done

      Feature Overview (mandatory - Complete while in New status)
      Delivering RHOSO Lightspeed as a separate operator would result in greater release flexibility and the possibility to include the latest documentation if delivering as a trailing release.

      Goals (mandatory - Complete while in New status)
      RHOSO Lightspeed should be possible to install as separate entity from the OpenStack install in OpenShift

      Requirements (mandatory -_ Complete while in Refinement status):
      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?
      RHOSO Lightspeed should be possible to install via operator as its own entity   Yes
      CI?    
      RAG Image?    

       

      Done - Acceptance Criteria (mandatory - Complete while in Refinement status):
      Acceptance Criteria articulates and defines the value proposition - what is required to meet the goal and intent of this Feature. The Acceptance Criteria provides a detailed definition of scope and the expected outcomes - from a users point of view

      The RHOSO Lightspeed Operator can be installed and uninstalled standalone from the OpenStack Operator

      Use Cases - i.e. User Experience & Workflow: (Initial completion while in Refinement status):
      Include use case diagrams, main success scenarios, alternative flow scenarios.
      <your text here>

      Out of Scope _{}(Initial completion while in Refinement status):{_}
      High-level list of items or persona’s that are out of scope.
      This operator will depend on OpenShift Lightspeed and it is out of scope building an operator that is not dependent on OCPLS

      Documentation Considerations _{}(Initial completion while in Refinement status):{_}
      Provide information that needs to be considered and planned so that documentation will meet customer needs. If the feature extends existing functionality, provide a link to its current documentation..
      <your text here>

       

      Questions to Answer _{}(Initial completion while in Refinement status):{_}
      Include a list of refinement / architectural questions that may need to be answered before coding can begin.

      • Is it worth to "bundle" the Lightspeed Operator with the OpenStack operator in the future? (Not needed for MVP)

      Background and Strategic Fit (Initial completion while in Refinement status):
      Provide any additional context is needed to frame the feature.

      Decoupling Lightspeed from the OpenStack Operator's lifecycle provides greater release flexibility. Crucially, the trailing release schedule allows the Lightspeed RAG image to be shipped after the core RHOSO release, enabling the inclusion of the latest, fully updated documentation.

              rh-ee-sherlofs Simon Herlofsson
              rh-ee-sherlofs Simon Herlofsson
              Simon Herlofsson Simon Herlofsson
              Edu Alcaniz Edu Alcaniz
              rhos-workloads-lightspeed
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: