Feature Overview

Currently, RHOSO Lightspeed is packaged and delivered as part of the main openstack-operator. This tightly couples its release lifecycle to the core RHOSO product, forcing the Lightspeed RAG (Retrieval-Augmented Generation) image to be built at the same time as the main release.

This creates a problem due to final product documentation often being incomplete or still undergoing changes when the build occurs. As a result, Late doc changes won’t be included in the RAG.

This feature will decouple RHOSO Lightspeed by creating a new, standalone operator. This strategic shift moves Lightspeed from being "part of the 18.0 releases" to a "trailing" release model.

Goals
The primary goal is to improve the accuracy and reliability of RHOSO Lightspeed answers by by decoupling from the openstack-operator and adopting a "trailing release" schedule to ensures the RAG is trained on the final, published documentation.

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.

Done - Acceptance Criteria:

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

Use Cases - i.e. User Experience & Workflow:

• user deploys Lightspeed via manually deployed Lightspeed operator additionally on OCP cluster running RHOSO ctlplane
• user deploys Lightspeed via manually deployed Lightspeed operator on OCP cluster, where ou
• user deploys Lightspeed via Lightspeed operator deployed by openstack-operator

Out of Scope {}{}(Initial completion while in Refinement status):
This operator will depend on OpenShift Lightspeed and it is out of scope building an operator that is not dependent on OCPLS

Documentation Considerations:

Every deployment use case will have to be documented.

Questions to Answer:
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?
  • Bundling would mean we won't be able to build Lightspeed operator separately in Conflux and we need to avoid dependency on openstack-operator build process, so the answer is no.

Background and Strategic Fit:

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.