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

Multi-cluster GitOps: User documentation

XMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Done
    • Icon: Critical Critical
    • None
    • None
    • None
    • False
    • Hide

      None

      Show
      None
    • False
    • GITOPS-8817Multi-cluster GitOps - GA
    • 0% To Do, 0% In Progress, 100% Done

      Feature Overview

      With the GA of Multi-Cluster GitOps (argocd-agent), users will expect documentation on various topics so they can get started and successfully setup and run Multi-Cluster GitOps.

      The documentation should talk about Day 1 and Day 2 Operations for running both, the principal and agent components on OpenShift Cluster Platform.

      Goals

      • Provide comprehensive user-facing documentation specific to installing, running and maintaining argocd-agent on OpenShift Cluster Platform
      • Provide link-outs to upstream documentation where feasible, so we can keep replication and sync of documentation between upstream and downstream to a minimum.

      Requirements

      Requirements Notes IS MVP
      System requirements are documented   Y
      General concepts and differences to classical GitOps are documented   Y
      Brief overview about agent modes are documented   Y
      mTLS requirements are documented   Y
      Installation steps for principal component is documented   Y
      Installation steps for agent component is documented   Y
      Configuration options for principal and agent components are documented   Y
           

      Use Cases

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

      Out of scope

      <Defines what is not included in this story>

      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/QE Considerations

      < 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 a doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>
      < 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>

      Definition of Ready

      • The objectives of the feature are clearly defined and aligned with the business strategy.
      • All feature requirements have been clearly defined by Product Owners.
      • The feature has been broken down into epics.
      • The feature has been stack ranked.
      • Definition of the business outcome is in the Outcome Jira (which must have a parent Jira).

              jgwest Jonathan West
              jfischer@redhat.com Jann Fischer
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: