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

Enable GitOps-Driven Adoption Workflow for RHOSP 17.1 to RHOSO 18 Upgrade via ArgoCD and Kustomize

XMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • GitOps
    • None
    • RHOSSTRAT-1062GitOps-Driven Lifecycle Management for Red Hat OpenStack Services on OpenShift (RHOSO)
    • Not Selected
    • False
    • False
    • Hide

      None

      Show
      None
    • 0
    • 0
    • 100% To Do, 0% In Progress, 0% Done
    • rhos-ops-day1day2-upgrades

      Feature Request Overview 

      Customers upgrading from Red Hat OpenStack Platform (RHOSP) 17.1 to Red Hat OpenStack Services on OpenShift (RHOSO) 18 currently follow a written procedure for the Adoption Mechanism. However, this process is manual and lacks GitOps integration. The goal of this feature request is to enhance the upgrade experience by providing documented examples of how to automate the Adoption Mechanism using GitOps practices with ArgoCD and Kustomize, improving consistency, traceability, and operational efficiency.

      Business justification (mandatory - Complete while in New status)
      How would this feature benefit the customer?

      • Provides a repeatable and automated upgrade process aligned with GitOps principles.
      • Reduces the potential for human error during control plane and data plane adoption.
      • Improves visibility and auditability of the upgrade workflow via Git history.
      • Aligns with customers’ existing GitOps pipelines and CI/CD best practices.
      • Accelerates time-to-value for customers adopting RHOSO, lowering operational overhead.

      Functional requirements (mandatory - Complete while in New status){_}

      • Provide official documentation with a GitOps-compatible version of the RHOSP to RHOSO adoption steps.
      • Include example ArgoCD Application manifests and kustomization.yaml files covering:
        • Adoption preparation
        • Control plane CR deployments
        • Dataplane service updates
        • Reboot orchestration
      • Offer guidance for structuring a Git repository to manage the RHOSO upgrade lifecycle via GitOps.
      • Document rollback strategies using GitOps tooling.
      • Include validation/test playbooks for pre- and post-adoption checks (via ArgoCD hooks or Jobs).

      Describe the customer impact{}

      This feature would significantly improve the day-2 operational experience of RHOSO adoption by enabling automation, auditability, and integration into existing GitOps workflows. It supports scaling and repeatability across environments and aligns with how cloud-native customers manage modern infrastructure updates.

      (Optional) Point of contact

      • Provide any additional points of contact for this feature request, such as an account executive, SA, or TAM: 
      •  

      (Optional) Additional links

      Click More > Link to add any links to issues, such as an outcome, that are related to this feature request.

      Feature Overview (mandatory - Complete while in New status)
      An elevator pitch (value statement) that describes the Feature in a clear, concise way. ie: Executive Summary of the user goal or problem that is being solved, why does this matter to the user? The “What & Why”... 
      <your text here>

      Goals (mandatory - Complete while in New status)
      Provide high-level goal statement, providing user context and expected user outcome(s) for this Feature

      • Who benefits from this Feature, and how? 
      • What is the difference between today’s current state and a world with this Feature?
        <your text here>

      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?
           
           

       
      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

      <your text here>
      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.
      <your text here>
      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.
      <your text here>
      Background and Strategic Fit (Initial completion while in Refinement status):
      Provide any additional context is needed to frame the feature.
      <your text here>
      Customer Considerations _ _(Initial completion while in Refinement status):
      Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.
      <your text here>
      Team Sign Off (Completion while in Planning status)

      • All required Epics (known at the time) are linked to the this Feature
      • All required Stories, Tasks (known at the time) for the most immediate Epics have been created and estimated
      • Add - Reviewers name, Team Name
      • Acceptance == Feature as “Ready” - well understood and scope is clear - Acceptance Criteria (scope) is elaborated, well defined, and understood
      • Note: Only set FixVersion/s: on a Feature if the delivery team agrees they have the capacity and have committed that capability for that milestone
        Reviewed By Team Name Accepted Notes
               
               
               
               

              rhn-engineering-apevec Alan Pevec
              pnavarro@redhat.com Pedro Navarro Perez
              Pedro Navarro Perez Pedro Navarro Perez
              Edu Alcaniz Edu Alcaniz
              rhos-dfg-upgrades
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated: