Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-8786

GitOps on managed OpenShift on HyperShift

XMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • None
    • False
    • Hide

      None

      Show
      None
    • False
    • GITOPS-8785GitOps support for the OpenShift product suite
    • 100% To Do, 0% In Progress, 0% Done

      < High-Level description of the feature ie: Executive Summary >

      Goals

      Customers using either our managed and unmanaged offerings on Hypershift want to run OpenShift GitOps on their platform of choice. This is true for our offerings on the Hyperscalers (ARO, ROSA) as well as for OSD and custom environments.

      We want to make sure that

      • The GitOps Operator can be installed on those platforms as easy as it is on classic OCP,
      • We have tested and vetted the use of GitOps Operator for common use-cases (namespace-scoped, cluster-scoped) on those platforms

      Requirements

      Requirements Notes IS MVP
      OpenShift GitOps Operator is available and tested for ARO on HCP    
      OpenShift GitOps Operator is available and tested for ROSA on HCP    
      OpenShift GitOps Operator is available and tested for OSD on HCP    
      OpenShift GitOps Operator is available and tested for IPI/UPI on HCP Done  
        • (Optional) Use Cases

      < What are we making, for who, and why/what problem are we solving?>

      Out of scope

      • Implementation of any Hypershift or managed-offering related changes or use-case (i.e. use of specific APIs)
      •  

      Dependencies

      < Link or at least explain any known dependencies. >

      Background, and strategic fit

      < What does the person writing code, testing, documenting need to know? >

      Assumptions

      < Are there assumptions being made regarding prerequisites and dependencies?>

      < Are there assumptions about hardware, software or people resources?>

      Customer Considerations

      < Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

      Documentation Considerations

      < What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >

      What does success look like?

      < Does this feature have doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>

      QE Contact

      < Are there assumptions being made regarding prerequisites and dependencies?>

      < Are there assumptions about hardware, software or people resources?>

      Impact

      < If the feature is ordered with other work, state the impact of this feature on the other work>

      Related Architecture/Technical Documents

      <links>

      Done Checklist

      • Acceptance criteria are met
      • Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
      • User Journey automation is delivered
      • Support and SRE teams are provided with enough skills to support the feature in production environment

              jfischer@redhat.com Jann Fischer
              wtam_at_redhat William Tam
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: