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

Native support for Source Hydrator feature in OpenShift GitOps

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • None
    • None
    • Native support for Source Hydrator feature in OpenShift GitOps
    • False
    • Hide

      None

      Show
      None
    • False
    • To Do
    • 100% To Do, 0% In Progress, 0% Done

      Epic Goal

      • Source Hydrator is a new feature introduced in Argo CD. This feature enables the rendered manifests pattern to be used, so that Users can use the git workflows to review the actual changes in the manifests before applying them to the cluster.

      Why is this important?

      • Currently it is complex for customers to try this upstream feature in an OpenShift Cluster with the Operator.

      Scenarios

      1. ...

      SDLC Questionnaire

      S.No Questions Yes/No Sample JIRA Epic
      1 Does this Epic address a change in way the product is being used? (eg: Adding support for OpenShift GitOps to be used in ROSA cluster with HCP) Yes/No GITOPS-5223
      2 Does this  Epic require a change in  the application's runtime - Upgrade of operator-sdk, OLM, client-go, go-toolset ? Yes/No GITOPS-8104
      3 Does this Epic primarily dealing with introducing a new security related feature (eg: Introduce SSO support) Yes/No GITOPS-437, GITOPS-547
      4 Does this Epic primarily dealing with the  modification of  an existing security feature ? (Eg: Supporting of External  Authentication for SSO)  Yes/No GITOPS-8017
      5 Does this Epic require changes to any cryptographic library ( Eg: FIPS support for OpenShift GitOps) Yes/No GITOPS-6365
      6 Does this Epic require any new or change in the existing cryptographic algorithms used in the product  (Eg: Using GPG verification for manifests, Upgrading from SHA256 to SHA512) Yes/No GITOPS-3049
      7 Does this Epic require any change in existing  authentication mechanisms (eg: Argo CD Auth integration with OpenShift, Kerberos to OAuth) Yes/No GITOPS-437 GITOPS-547 GITOPS-3246 GITOPS-1330
      8 Does this Epic require any change in authorisation mechanism (Eg: Using RBAC and service accounts impersonation for App Sync) Yes/No GITOPS-3501
      9 Does this Epic require a change in the Communication protocol ( Eg: Using TLS to encrypt data traffic to/from Redis cache) Yes/No GITOPS-720
      10 Does this Epic require a change in how External Data is parsed and validated ? ( Eg: Change from JSON to Protobuf) Yes/No  
      11 Does this Epic require a change in core libraries or runtime (Eg: go compiler upgrade, Changing Operator SDK, controller-runtime, client-go versions) Yes/No GITOPS-7295
      12 Does this Epic require exposing any internal service to internet (Eg: Allow exposing Argo CD Agent principal via Route, using ArgoCD CR) Yes/No GITOPS-7728
      13 Does this Epic require a change in any existing gRPC service APIs Yes/No  
      14 Does this Epic require a change in any new external service (Eg: Support for OCI container registry for storing manifests) Yes/No GITOPS-4432
      15 Does this Epic require a change in the tenancy model ? (Eg: Supporting Apps/Appsets in Any namespace, cluster and repo credentials in any namespace) Yes/No GITOPS-917
      GITOPS-3754
      16 Does this Epic require any addition/modification of RBAC resources (Service Account, Role, RoleBinding, ClusterRole, ClusterRoleBinding) ? Yes/No  
      17 Does this Epic require a feature that needs to be enabled only for cluster scoped Argo CD instances ? Yes/No  

      Other Considerations

      • <Call out anything explicitly as Out of Scope?>
      • <Call out internal and external dependencies?>
      • <Are there any known previous works?>
      • <Any unanswered questions?>

      Definition of Ready

      • The epic has been broken down into stories.
      • Stories have been scoped.
      • The epic has been stack ranked.

      Definition of Done

      • Code Complete:
        • All code has been written, reviewed, and approved.
      • Tested:
        • Unit tests have been written and passed.
        • Integration tests have been completed.
        • System tests have been conducted, and all critical bugs have been fixed.
        • Tested on OpenShift either upstream or downstream on a local build.
      • Documentation:
        • User documentation or release notes have been written.
      • Build:
        • Code has been successfully built and integrated into the main repository / project.
      • Review:
        • Code has been peer-reviewed and meets coding standards.
        • All acceptance criteria defined in the user story have been met.
        • Tested by reviewer on OpenShift.
      • Deployment:
        • The feature has been deployed on OpenShift cluster for testing.
      • Acceptance:
        • Product Manager or stakeholder has reviewed and accepted the work.

              Unassigned Unassigned
              rh-ee-anjoseph Anand Francis Joseph
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: