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 a RPM that contains a set of Kustomize manifests that mimic upstream's "core" mode installation. 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-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)

• The rpm on installation, extracts the kubernetes manifests to the readonly manifests directory /usr/lib/microshift/manifests.d/
• Each version of the manifests we publish are available to download from an official Red Hat yum repository

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