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

Productize versioned upstream manifests

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • Productize versioned upstream manifests
    • False
    • None
    • False
    • To Do
    • SECFLOWOTL-89 - Support a small footprint GitOps for MicroShift
    • 0% To Do, 0% In Progress, 100% Done

      Epic Goal

      In order to support GitOps/Argo CD with minimum footprint on Microshift devices, we need to get rid of all unnecessary workloads and compute hogs.

      According to the requirements spelled out by GITOPS-3374, we do not need to support any of the advanced features that our GitOps Operator provides (e.g. High Availability, upscaling capabilites, namespace scope support, etc). Thus, it makes sense to remove the Operator from the required workloads on Microshift.

      The goal of this Epic is to produce and make available a set of Kustomize manifests that mimic upstream's "core" mode installation, that is, after applying the manifests the following Argo CD assets and components should be configured on the cluster:

      • The CRDs
      • Network policies to allow communication between components
      • All assets required for configuring the Argo CD instance (e.g. argocd-cm, argocd-cmd-params-cm, etc)
      • The argocd-application-controller workload
      • The argocd-applicationset-controller workload
      • The argocd-repo-server workload
      • The argocd-redis workload

      All of the above mentioned requirements are available from Argo CD's "core-install" Kustomize base as can be found at https://github.com/argoproj/argo-cd/tree/master/manifests/core-install, so this could (but doesn't have to) be used as a starting point for our productized version of it.

      Additional requirements for the manifests to be produced:

      • The Kustomize manifests must not make use of any remote bases, because network connectivity may not be assumed
      • The images we refer to in those manifests must be our productized version of e.g. Argo CD, Redis, etc. No upstream or otherwise non-productized image is allowed to be referred to.
      • We need to accommodate for any Microshift specifics, for example, satisfy any default security context constraints which may not be present in upstream manifests
      • Versioned Kustomize manifests should follow Operator versioning for minor versions, e.g. for OpenShift GitOps Operator 1.11.z, we need to produce upstream manifests based on the Argo CD version shipped with it

      Why is this important?

      We need to support GitOps on Microshift with the lowest possible footprint. Since the Operator has a footprint by itself, and doesn't provide much value given the requirements for GitOps on Microshift, we don't necessarily need to provision it on Microshift devices. Instead, we go with plain Kustomize manifests.

      This has the advantages of:

      • A lower footprint,
      • Less complexity on the Microshift device,
      • Easier self-management of Argo CD using GitOps principles (e.g. store the Kustomize manifests in Git, point Argo CD to them, let Argo CD manage itself).

      Scenarios

      1. Supporting GitOps on Microshift without the use of the Operator

      Acceptance Criteria (Mandatory)

      • A set of Kustomize manifests for the most current GitOps/Argo CD version combination is available that can be used to install Argo CD in "core" mode on a Microshift cluster (i.e. simply by running oc apply -k) and by including them in Microshift's workload installation procedures as described in https://github.com/openshift/microshift/blob/main/docs/user/howto_config.md#auto-applying-manifests
      • Each version of the manifests we publish are available to download from an official Red Hat site (e.g. redhat.com)

      Dependencies (internal and external)

      1. This is part of the "Install GitOps on Microshift without the Operator" stream. If we decide to go with the Operator instead, this Epic is to be ignored and can be closed.

      Previous Work (Optional):

      1. ...

      Open questions::

      1. ...
      •  

      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

              isequeir@redhat.com Ishita Sequeira
              jfischer@redhat.com Jann Fischer
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: