diff --git a/argocd-operator/.readthedocs.yml b/.readthedocs.yml similarity index 75% rename from argocd-operator/.readthedocs.yml rename to .readthedocs.yml index c5d6d9a9148..315e0cbb2a8 100644 --- a/argocd-operator/.readthedocs.yml +++ b/.readthedocs.yml @@ -5,10 +5,10 @@ version: 2 formats: all mkdocs: fail_on_warning: false - configuration: mkdocs.yml + configuration: argocd-operator/mkdocs.yml python: install: - - requirements: docs/requirements.txt + - requirements: argocd-operator/docs/requirements.txt build: os: "ubuntu-22.04" tools: diff --git a/Makefile b/Makefile index bae2412febe..e8fd602b53a 100644 --- a/Makefile +++ b/Makefile @@ -68,6 +68,9 @@ OPERATOR_SDK_VERSION ?= v1.35.0 # Set the path to Operator SDK - OPERATOR_SDK_VERSION will be ignored. OPERATOR_SDK ?= bin/operator-sdk +# K8s version to use for reference documentation. +KUBERNETES_API_VERSION ?= 1.35 + # Get the currently used golang install path (in GOPATH/bin, unless GOBIN is set) ifeq (,$(shell go env GOBIN)) GOBIN=$(shell go env GOPATH)/bin @@ -381,3 +384,22 @@ GOFLAGS="" GOBIN=$(PROJECT_DIR)/bin go install $(2) ;\ rm -rf $$TMP_DIR ;\ } endef + +.PHONY: apidocs-gen +apidocs-gen: ## Generate API documentation. + $(call crd-ref-docs,./api/v1alpha1/,./docs/reference/api-v1alpha1.md) + $(call crd-ref-docs,./api/v1beta1/,./docs/reference/api-v1beta1.md) + +define crd-ref-docs +# The config have the k8s version injected so it does not have to be updated there +cd argocd-operator && go run github.com/elastic/crd-ref-docs@v0.3.0 \ + --config=<(sed 's/__KUBERNETES_API_VERSION__/$(KUBERNETES_API_VERSION)/' ./docs/crd-ref-docs.config.yaml) \ + --source-path=$(1) \ + --log-level=info \ + --renderer=markdown \ + --output-path=$(2) +endef + +.PHONY: serve-docs +serve-docs: apidocs-gen ## Serve documentation locally using mkdocs in a container + $(CONTAINER_RUNTIME) run --rm -it -p 8000:8000 -v $(PWD)/argocd-operator:/argocd-operator:Z -w /argocd-operator --name argocd-operator-mkdocs registry.access.redhat.com/ubi9/python-311:latest /bin/bash -c "pip install -r docs/requirements.txt && mkdocs serve -a 0.0.0.0:8000" diff --git a/argocd-operator/Makefile b/argocd-operator/Makefile index c8e40f94031..ca59018fd20 100644 --- a/argocd-operator/Makefile +++ b/argocd-operator/Makefile @@ -43,9 +43,6 @@ BUNDLE_METADATA_OPTS ?= $(BUNDLE_CHANNELS) $(BUNDLE_DEFAULT_CHANNEL) # This is useful for CI or a project to utilize a specific version of the operator-sdk toolkit. OPERATOR_SDK_VERSION ?= v1.35.0 -# K8s version to use for reference documentation. -KUBERNETES_API_VERSION ?= 1.35 - GOSEC_VERSION ?= v2.22.7 GOLANGCILINT_VERSION ?= v2.12.2 @@ -371,21 +368,3 @@ update-dependencies-argocd: update-dependencies-gitops-promoter: hack/update-dependencies-script/gitops-promoter/run.sh -.PHONY: apidocs-gen -apidocs-gen: ## Generate API documentation. - $(call crd-ref-docs,./api/v1alpha1/,./docs/reference/api-v1alpha1.md) - $(call crd-ref-docs,./api/v1beta1/,./docs/reference/api-v1beta1.md) - -define crd-ref-docs -# The config have the k8s version injected so it does not have to be updated there -go run github.com/elastic/crd-ref-docs@v0.3.0 \ - --config=<(sed 's/__KUBERNETES_API_VERSION__/$(KUBERNETES_API_VERSION)/' ./docs/crd-ref-docs.config.yaml) \ - --source-path=$(1) \ - --log-level=info \ - --renderer=markdown \ - --output-path=$(2) -endef - -.PHONY: serve-docs -serve-docs: apidocs-gen ## Serve documentation locally using mkdocs in a container - $(CONTAINER_RUNTIME) run --rm -it -p 8000:8000 -v $(PWD):/argocd-operator:Z -w /argocd-operator --name argocd-operator-mkdocs registry.access.redhat.com/ubi9/python-311:latest /bin/bash -c "pip install -r docs/requirements.txt && mkdocs serve -a 0.0.0.0:8000" diff --git a/argocd-operator/docs/SECURITY.md b/argocd-operator/docs/SECURITY.md deleted file mode 100644 index cbf7d43b2b7..00000000000 --- a/argocd-operator/docs/SECURITY.md +++ /dev/null @@ -1,22 +0,0 @@ -# Security - -## Reporting a Vulnerability - -If you find a security related bug in Argo CD Operator, we kindly ask you for responsible -disclosure and for giving us appropriate time to react, analyze and develop a -fix to mitigate the found security vulnerability. - -Please report vulnerabilities via e-mail to the following address: - -* argocd-operator-security@redhat.com - -All vulnerabilities and associated information will be treated with full confidentiality. - -## Public Disclosure - -Security vulnerabilities will be disclosed via release notes. Release notes for a specific release can be found under the Releases section. For example, release notes for v0.3.0 can be found [here](https://github.com/argoproj-labs/argocd-operator/releases/tag/v0.3.0) and using the -[GitHub Security Advisories](https://github.com/argoproj-labs/argocd-operator/security/advisories) -feature to keep our community well informed, and will credit you for your findings (unless you prefer to stay anonymous, of course). - -!!! note - Please report the vulnerabilities related to Argo CD operator only. Please read Argo CD security [policy](https://github.com/argoproj/argo-cd/blob/master/SECURITY.md) if you would like to report any vulnerabilities related to Argo CD. diff --git a/argocd-operator/docs/developer-guide/contributing.md b/argocd-operator/docs/developer-guide/contributing.md deleted file mode 100644 index 062f1813ab9..00000000000 --- a/argocd-operator/docs/developer-guide/contributing.md +++ /dev/null @@ -1,43 +0,0 @@ -# Submitting code contributions to Argo CD Operator - -## Preface - -The Argo CD Operator project continuously grows, both in terms of features and community size. Thus, we need to take great care with any changes that affect compatibility, performance, scalability, stability and security of the Argo CD Operator. For this reason, every new feature or larger enhancement must be properly designed and discussed before it gets accepted into the code base. - -We do welcome and encourage everyone to participate in the Argo CD Operator project, but please understand that we can't accept each and every contribution from the community, for various reasons. - -If you want to submit code for a great new feature or enhancement, we kindly ask you to take a look at the -enhancement process outlined below before you start to write code or submit a PR. This will ensure that your idea is well aligned with the project's strategy and technical requirements, and it will help greatly in getting your code merged into our code base. - -Before submitting code for a new feature (and also, to some extent, for more complex bug fixes) please -[raise a Feature Request (enhancement proposal) or Bug Issue](https://github.com/argoproj-labs/argocd-operator/issues/new/choose) -first. - -_Please_ do not spend too much time on larger features or refactorings before the corresponding enhancement has been triaged. This may save everyone some amount of frustration and time, as the enhancement proposal might be rejected, and the code would never get merged. However, sometimes it's helpful to have some PoC code along with a proposal. - -We will do our best to triage incoming enhancement proposals quickly, with one of the following outcomes: - -* Accepted -* Declined -* Needs Discussion - -Depending on how many enhancement proposals we receive at given times, it may take some time until we can look at yours. - -## Quick start - -If you want a quick start contributing to Argo CD Operator, take a look at issues that are labeled with -[help wanted](https://github.com/argoproj-labs/argocd-operator/labels/help%20wanted) or [good first issue](https://github.com/argoproj-labs/argocd-operator/labels/good%20first%20issue). These are issues that were already triaged and accepted. - -## Proposal states - -**Accepted Proposals:** When a proposal is considered _Accepted_, it was decided that this enhancement would be valuable to the community at large and fits into the overall strategic roadmap of the project. Implementation of the issue may be started, either by the proposal's creator or another community member (including maintainers of the project). The issue should be refined enough by now to contain any concerns and guidelines to be taken into consideration during implementation. - -**Declined proposals:** We don't decline proposals lightly, and we will do our best to give a proper reasoning why we think that the proposal does not fit with the future of the project. Reasons for declining proposals may be (amongst others) that the change would be breaking for many, or that it does not meet the strategic direction of the project. Usually, discussion will be facilitated with the enhancement's creator before declining a proposal. Once a proposal is in _Declined_ state it's unlikely that we will accept code contributions for its implementation. - -**Needs discussion:** Sometimes, we can't completely understand a proposal from its GitHub issue and thus require more information on the original intent or more details about the implementation. If we are confronted with such an issue during the triage we expect the issue's creator to supply more information on their idea. - -## Design documents - -For some enhancement proposals (especially those that will change behavior of Argo CD Operator substantially, are attached with some caveats, or where upgrade/downgrade paths are not clear), a more formal design document will be required in order to fully discuss and understand the enhancement in the broader community. This requirement is usually determined during triage. If you submitted an enhancement proposal, we may ask you to provide this more formal write down, along with some concerns or topics that need to be addressed. Please consider adding visuals wherever possible to increase understanding of complex issues; we recommend using [Miro](https://miro.com/) as a visual aid tool. - -Design documents are usually submitted as a PR and use [this template](https://github.com/argoproj-labs/argocd-operator/blob/master/docs/proposals/001-proposal-template.md) as a guide what kind of information we're looking for. Discussion will take place in the review process. When a design document gets merged, we consider it as approved and code can be written and submitted to implement this specific design. \ No newline at end of file diff --git a/argocd-operator/docs/developer-guide/development.md b/argocd-operator/docs/developer-guide/development.md index cab6669409b..f2a3f22321b 100644 --- a/argocd-operator/docs/developer-guide/development.md +++ b/argocd-operator/docs/developer-guide/development.md @@ -4,8 +4,6 @@ The requirements for building the operator are fairly minimal. -* Go 1.16+ -* Operator SDK 1.11.0+ * Bash or equivalent * Docker @@ -50,7 +48,7 @@ make bundle-build bundle-push To override the name of the bundle image, specify the `BUNDLE_IMG` tag, for example ``` bash -make bundle-build bundle-push BUNDLE_IMG=quay.io/my-org/argocd-operator-bundle:latest +make bundle-build bundle-push BUNDLE_IMG=quay.io/my-org/gitops-operator-bundle:latest ``` ### Development Process @@ -91,14 +89,14 @@ Build the development container image. Override the name of the image to build by specifying the `IMG` variable. ``` bash -make docker-build IMG=quay.io/my-org/argocd-operator:latest +make docker-build IMG=quay.io/my-org/gitops-operator:latest ``` Push the development container image. Override the name of the image to push by specifying the `IMG` variable. ``` bash -make docker-push IMG=quay.io/my-org/argocd-operator:latest +make docker-push IMG=quay.io/my-org/gitops-operator:latest ``` Generate the bundle artifacts. @@ -106,15 +104,15 @@ Override the name of the development image by specifying the `IMG` variable. ``` bash rm -fr bundle/ -make bundle IMG=quay.io/my-org/argocd-operator:latest +make bundle IMG=quay.io/my-org/gitops-operator:latest ``` Build and push the development bundle image. Override the name of the bundle image by specifying the `BUNDLE_IMG` variable. ``` bash -make bundle-build BUNDLE_IMG=quay.io/my-org/argocd-operator-bundle:latest -make bundle-push BUNDLE_IMG=quay.io/my-org/argocd-operator-bundle:latest +make bundle-build BUNDLE_IMG=quay.io/my-org/gitops-operator-bundle:latest +make bundle-push BUNDLE_IMG=quay.io/my-org/gitops-operator-bundle:latest ``` Build and push the development catalog image. @@ -122,11 +120,11 @@ Override the name of the catalog image by specifying the `CATALOG_IMG` variable. Specify the bundle image to include using the `BUNDLE_IMG` variable ``` bash -make catalog-build BUNDLE_IMG=quay.io/my-org/argocd-operator-bundle:latest CATALOG_IMG=quay.io/my-org/argocd-operator-index:latest -make catalog-push CATALOG_IMG=quay.io/my-org/argocd-operator-index:latest +make catalog-build BUNDLE_IMG=quay.io/my-org/gitops-operator-bundle:latest CATALOG_IMG=quay.io/my-org/gitops-operator-index:latest +make catalog-push CATALOG_IMG=quay.io/my-org/gitops-operator-index:latest ``` -For more infomation see [build operator images to test on a cluster.](https://argocd-operator.readthedocs.io/en/latest/developer-guide/development/#building-the-operator-images-to-test-on-a-cluster) +For more infomation see [build operator images to test on a cluster.](https://gitops-operator.readthedocs.io/en/latest/developer-guide/development/#building-the-operator-images-to-test-on-a-cluster) Once the operator is installed, you would need to configure an ArgoCD instance that the operator would manage. The sample instance configuration is below: @@ -146,7 +144,7 @@ Store your ArgoCD configuration in a yaml file and execute below command to conf kubectl apply -f ``` -For configuring specific properties based on the use case, you can look at the entire list of the configurable properties [here.](https://argocd-operator.readthedocs.io/en/latest/reference/argocd/) +For configuring specific properties based on the use case, you can look at the entire list of the configurable properties [here.](https://gitops-operator.readthedocs.io/en/latest/reference/argocd/) ### Build and Serve Argo CD Operator Docs diff --git a/argocd-operator/docs/developer-guide/e2e-test-guide.md b/argocd-operator/docs/developer-guide/e2e-test-guide.md index a210084e6e4..1b76a738e07 100644 --- a/argocd-operator/docs/developer-guide/e2e-test-guide.md +++ b/argocd-operator/docs/developer-guide/e2e-test-guide.md @@ -1,3 +1,3 @@ # Argo CD Operator E2E Test Guide -E2E tests are written using Ginkgo. See [documentation within the source repository](https://github.com/argoproj-labs/argocd-operator/tree/master/tests/ginkgo) for additional information. +E2E tests are written using Ginkgo. See [documentation within the source repository](https://github.com/redhat-developer/gitops-operator/tree/master/test/openshift/e2e/ginkgo) for additional information. diff --git a/argocd-operator/docs/index.md b/argocd-operator/docs/index.md index 78113b5ecad..e0ac620ce52 100644 --- a/argocd-operator/docs/index.md +++ b/argocd-operator/docs/index.md @@ -1,10 +1,10 @@ -# Argo CD Operator +# GitOps Operator -A Kubernetes operator for managing Argo CD clusters. +An operator for managing Argo CD clusters, for OpenShift and Kubernetes ## Overview -The Argo CD Operator manages the full lifecycle for [Argo CD](https://argoproj.github.io/argo-cd/) and its +The GitOps Operator manages the full lifecycle for [Argo CD](https://argoproj.github.io/argo-cd/) and its components. The operator's goal is to automate the tasks required when operating an Argo CD cluster. Beyond installation, the operator helps to automate the process of upgrading, backing up and restoring as needed and @@ -12,10 +12,16 @@ remove the human as much as possible. In addition, the operator aims to provide environment by configuring Prometheus to aggregate, visualize and expose the metrics already exported by Argo CD. -The operator aims to provide the following, and is a work in progress. +## Features -* Easy configuration and installation of the Argo CD components with sane defaults to get up and running quickly. -* Provide seamless upgrades to the Argo CD components. -* Ability to back up and restore an Argo CD cluster from a point in time or on a recurring schedule. +The operator aims to provide the following: + +* Easy configuration and installation of the Git Ops components with sane defaults to get up and running quickly. + * The Argo CD itself + * [Argo CD Image Updater](https://argocd-image-updater.readthedocs.io/en/stable/) + * [Argo Rollouts](https://argoproj.github.io/rollouts/) + * [GitOps Promoter](https://gitops-promoter.readthedocs.io/en/latest/) +* Provide seamless upgrades to the operated components. * Aggregate and expose the metrics for Argo CD and the operator itself using Prometheus. * Autoscale the Argo CD components as necessary to handle variability in demand. + diff --git a/argocd-operator/docs/install/manual.md b/argocd-operator/docs/install/manual.md deleted file mode 100644 index 24bd354e50d..00000000000 --- a/argocd-operator/docs/install/manual.md +++ /dev/null @@ -1,147 +0,0 @@ -# Manual Installation using kustomize - -The following steps can be used to manually install the operator on any Kubernetes environment with minimal overhead. - -!!! info - Several of the steps in this process require the `cluster-admin` ClusterRole or equivalent. - -## Cluster - -This guide uses [minikube](https://minikube.sigs.k8s.io/) to deploy a Kubernetes cluster locally, follow the -instructions for your platform to install. - -Run minikube with a dedicated profile. Adjust the system resources as needed for your platform. - -```bash -minikube start -p argocd --cpus=4 --disk-size=40gb --memory=8gb -``` - -## Manual Install - -The following section outlines the steps necessary to deploy the ArgoCD Operator manually using standard Kubernetes -manifests. Note that these steps generates the manifests using kustomize. - -!!! info - Make sure you download the source code from release section: https://github.com/argoproj-labs/argocd-operator/releases. Compiling from the source code cloned off main repo may not provide the most stable result. - -### Namespace - -By default, the operator is installed into the `argocd-operator-system` namespace. To modify this, update the -value of the `namespace` specified in the `config/default/kustomization.yaml` file. - -### Conversion Webhook Support - -ArgoCD `v1alpha1` CRD has been **deprecated** starting from **argocd-operator v0.8.0**. To facilitate automatic migration of existing v1alpha1 ArgoCD CRs to v1beta1, conversion webhook support has been introduced. - -By default, the conversion webhook is disabled for the manual(non-OLM) installation of the operator. Users can modify the configurations to enable conversion webhook support using the instructions provided below. - -!!! warning - Enabling the webhook is optional. However, without conversion webhook support, users are responsible for migrating any existing ArgoCD v1alpha1 CRs to v1beta1. - -##### Enable Webhook Support - -To enable the operator to utilize the `cert-manager` for automated webhook certificate management, ensure that it is installed in the cluster. Use [this](https://cert-manager.io/docs/installation/) guide to install `cert-manager` if not present on the cluster. - -Add cert-manager annotation to CRD in `config/crd/patches/cainjection_in_argocds.yaml` file. -```yaml -metadata: - name: argocds.argoproj.io - annotations: - cert-manager.io/inject-ca-from: $(CERTIFICATE_NAMESPACE)/$(CERTIFICATE_NAME) -``` - -Enable `../certmanager` directory under the `resources` section in `config/default/kustomization.yaml` file. -```yaml -resources: -..... -- ../webhook -# [CERTMANAGER] To enable cert-manager, uncomment all sections with 'CERTMANAGER'. 'WEBHOOK' components are required. -- ../certmanager -``` - -Enable all the `vars` under the `[CERTMANAGER]` section in `config/default/kustomization.yaml` file. -```yaml -vars: -# [CERTMANAGER] To enable cert-manager, uncomment all sections with 'CERTMANAGER' prefix. -- name: CERTIFICATE_NAMESPACE # namespace of the certificate CR - objref: - kind: Certificate - group: cert-manager.io - version: v1 - name: serving-cert # this name should match the one in certificate.yaml - fieldref: - fieldpath: metadata.namespace -- name: CERTIFICATE_NAME - objref: - kind: Certificate - group: cert-manager.io - version: v1 - name: serving-cert # this name should match the one in certificate.yaml -- name: SERVICE_NAMESPACE # namespace of the service - objref: - kind: Service - version: v1 - name: webhook-service - fieldref: - fieldpath: metadata.namespace -- name: SERVICE_NAME - objref: - kind: Service - version: v1 - name: webhook-service -``` - -Additionally, set the `ENABLE_CONVERSION_WEBHOOK` environment variable in `config/default/manager_webhook_patch.yaml` file to enable the conversion webhook. -```yaml - - name: manager - env: - - name: ENABLE_CONVERSION_WEBHOOK - value: "true" -``` - -### Deploy Operator - -Deploy the operator. This will create all the necessary resources, including the namespace. For running the make command you need to install go-lang package on your system. - -```bash -make deploy -``` - -If you want to use your own custom operator container image, you can specify the image name using the `IMG` variable. - -```bash -make deploy IMG=quay.io/my-org/argocd-operator:latest -``` - -The operator pod should start and enter a `Running` state after a few seconds. - -```bash -kubectl get pods -n argocd-operator-system -``` - -```bash -NAME READY STATUS RESTARTS AGE -argocd-operator-controller-manager-6c449c6998-ts95w 2/2 Running 0 33s -``` -!!! info - If you see `Error: container's runAsUser breaks non-root policy`, means container wants to have admin privilege. run `oc adm policy add-scc-to-user privileged -z default -n argocd-operator-system` to enable admin on the namespace and change the following line in deployment resource: `runAsNonRoot: false`. This is a quick fix to make it running, this is not a suggested approach for *production*. - -!!! info - ArgoCD instance deployed by operator will be namespace scoped. To make it cluster scoped, add environment variable `ARGOCD_CLUSTER_CONFIG_NAMESPACES` with `argocd-operator-system` as a value to `argocd-operator-controller-manager` deployment. - -## Usage - -Once the operator is installed and running, new ArgoCD resources can be created. See the [usage][docs_usage] -documentation to learn how to create new `ArgoCD` resources. - -## Cleanup - -To remove the operator from the cluster, run the following comand. This will remove all resources that were created, -including the namespace. -```bash -make undeploy -``` - - - -[docs_usage]:../usage/basics.md diff --git a/argocd-operator/docs/install/olm.md b/argocd-operator/docs/install/olm.md deleted file mode 100644 index 41d7267fc56..00000000000 --- a/argocd-operator/docs/install/olm.md +++ /dev/null @@ -1,231 +0,0 @@ -# OLM Install - -The following steps can be used to install the operator using the [Operator Lifecycle Manager][olm_home] on any Kubernetes -environment with minimal overhead. - -## Cluster Setup - -This guide uses [minikube](https://minikube.sigs.k8s.io/) to deploy a Kubernetes cluster locally, follow the -instructions for your platform to install. If you already have a Kubernetes cluster ready to go, skip to -the [OLM](#operator-lifecycle-manager) section. - -Run minikube with a dedicated profile. Adjust the system resources as needed for your platform. - -```bash -minikube start -p argocd --cpus=4 --disk-size=40gb --memory=8gb -``` - -## Operator Lifecycle Manager - -Install the OLM components manually. If you already have OLM installed, skip to the [Operator](#operator-install) section. - -Either - -- install OLM from [here](https://github.com/operator-framework/operator-lifecycle-manager/releases) - -or - -- install using the `operator-sdk` command -```bash -operator-sdk olm install -``` - -Verify that OLM is installed. There should be two new namespaces, `olm` and `operators` created as a result. - -```bash -kubectl get ns -``` - -``` -NAME STATUS AGE -kube-system Active 7d1h -default Active 7d1h -kube-public Active 7d1h -kube-node-lease Active 7d1h -operators Active 94s -olm Active 94s -``` - -Verify that the OLM Pods are running in the `olm` namespace. - -```bash -kubectl get pods -n olm -``` - -``` -NAME READY STATUS RESTARTS AGE -olm-operator-5b58594fc8-bzpq2 1/1 Running 0 2m10s -catalog-operator-6d578c5764-l5f5t 1/1 Running 0 2m10s -packageserver-7495fbf449-w4w6h 1/1 Running 0 80s -packageserver-7495fbf449-9jmpj 1/1 Running 0 80s -operatorhubio-catalog-pnsc7 1/1 Running 0 81s -``` - -That's it, OLM should be installed and availble to manage the Argo CD Operator. - -## Operator Install - -Use the following steps to install the operator using an OLM Catalog. - -### Namespace - -Create a new namespace for the operator. - -```bash -kubectl create namespace argocd -``` - -### Operator Catalog - -Create a `CatalogSource` in the `olm` namespace. This manifest references a container image that has the Argo CD -Operator packaged for use in OLM. For more information on packaging the operator, see the [development][docs_dev] documentation. - -```bash -kubectl create -n olm -f deploy/catalog_source.yaml -``` - -The `catalog_source.yaml` file can be found [in the `deploy` folder in the -repository](https://github.com/argoproj-labs/argocd-operator/tree/master/deploy). -It should look like this: - -```yaml -apiVersion: operators.coreos.com/v1alpha1 -kind: CatalogSource -metadata: - name: argocd-catalog -spec: - sourceType: grpc - image: quay.io/argoprojlabs/argocd-operator-registry@sha256:dcf6d07ed5c8b840fb4a6e9019eacd88cd0913bc3c8caa104d3414a2e9972002 # replace with your index image - displayName: Argo CD Operators - publisher: Argo CD Community -``` - -Verify that the Argo CD operator catalog has been created. - -```bash -kubectl get catalogsources -n olm -``` - -``` -NAME DISPLAY TYPE PUBLISHER AGE -argocd-catalog Argo CD Operators grpc Argo CD 6s -operatorhubio-catalog Community Operators grpc OperatorHub.io 25m -``` - -Verify that the registry Pod that serves the catalog is running. - -```bash -kubectl get pods -n olm -l olm.catalogSource=argocd-catalog -``` - -``` -NAME READY STATUS RESTARTS AGE -argocd-catalog-nxn79 1/1 Running 0 55s -``` - -### Operator Group - -Create an `OperatorGroup` in the `argocd` namespace that defines the namespaces that the Argo CD Operator will watch for -new resources. - -Please find the file `operator_group.yaml` in the [git -repository](https://github.com/argoproj-labs/argocd-operator/blob/master/deploy/operator_group.yaml). - -It's content looks like this: - -```yaml -apiVersion: operators.coreos.com/v1 -kind: OperatorGroup -metadata: - name: argocd-operator -``` - -```bash -kubectl create -n argocd -f deploy/operator_group.yaml -``` - -Verify that the new OperatorGroup was created in the `argocd` namespace. - -```bash -kubectl get operatorgroups -n argocd -``` - -``` -NAME AGE -argocd-operator 10s -``` - -### Subscription - -Once the OperatorGroup is present, create a new `Subscription` for the Argo CD Operator in the new `argocd` namespace. - -You can use the file [from the git -repository](https://github.com/argoproj-labs/argocd-operator/blob/master/deploy/subscription.yaml), it looks like this: - -```yaml -apiVersion: operators.coreos.com/v1alpha1 -kind: Subscription -metadata: - name: argocd-operator -spec: - channel: alpha - name: argocd-operator - source: argocd-catalog - sourceNamespace: olm -``` - -```bash -kubectl create -n argocd -f deploy/subscription.yaml -``` - -Verify that the Subscription was created in the `argocd` namespace. -```bash -kubectl get subscriptions -n argocd -``` - -```bash -NAME PACKAGE SOURCE CHANNEL -argocd-operator argocd-operator argocd-catalog alpha -``` - -The Subscription should result in an `InstallPlan` being created in the `argocd` namespace. - -```bash -kubectl get installplans -n argocd -``` - -``` -NAME CSV APPROVAL APPROVED -install-62hsr argocd-operator.v0.1.0 Automatic true -``` - -Finally, verify that the Argo CD Operator Pod is running in the `argocd` namespace. - -```bash -kubectl get pods -n argocd -``` - -``` -NAME READY STATUS RESTARTS AGE -argocd-operator-controller-manager-74b9ddb78c-lxzq2 2/2 Running 0 2m27s -``` - -## Usage - -Once the operator is installed and running, new ArgoCD resources can be created. See the [usage][docs_usage] -documentation to learn how to create new `ArgoCD` resources. - -## Cleanup - -You can clean up the operator resources by running the following commands. - -```bash -kubectl delete -n argocd -f deploy/subscription.yaml -kubectl delete -n argocd -f deploy/operator_group.yaml -kubectl delete -n olm -f deploy/catalog_source.yaml -kubectl delete namespace argocd -``` - -[docs_dev]:../developer-guide/development.md -[docs_usage]:../usage/basics.md -[olm_home]:https://github.com/operator-framework/operator-lifecycle-manager diff --git a/argocd-operator/docs/install/openshift.md b/argocd-operator/docs/install/openshift.md index ac51d2be398..dd1b17f80d9 100644 --- a/argocd-operator/docs/install/openshift.md +++ b/argocd-operator/docs/install/openshift.md @@ -12,8 +12,6 @@ cluster and select the Operators link, then select the OperatorHub link to displ Select the operator named `Argo CD` and click the **Install** button. You can select the namespace and deploy the operator. -In addition to the console interface, the [Operator Install][olm_install] section of the OLM Install Guide details the same method using manifests. - ## Manual Install The following steps can be used to manually install the operator in an OpenShift 4.x environment with minimal overhead. Note that these steps generates the manifests using kustomize. @@ -29,11 +27,11 @@ oc login -u kubeadmin ``` !!! info - Make sure you download the source code from release section: https://github.com/argoproj-labs/argocd-operator/releases. Compiling from the source code cloned off main repo may not provide the most stable result. + Make sure you download the source code from release section: https://github.com/redhat-developer/gitops-operator/releases. Compiling from the source code cloned off main repo may not provide the most stable result. ### Namespace -By default, the operator is installed into the `argocd-operator-system` namespace. To modify this, update the +By default, the operator is installed into the `openshift-gitops-operator` namespace. To modify this, update the value of the `namespace` specified in the `config/default/kustomization.yaml` file. ### Conversion Webhook Support @@ -86,21 +84,21 @@ make deploy If you want to use your own custom operator container image, you can specify the image name using the `IMG` variable. ```bash -make deploy IMG=quay.io/my-org/argocd-operator:latest +make deploy IMG=quay.io/my-org/gitops-operator:latest ``` The operator pod should start and enter a `Running` state after a few seconds. ```bash -oc get pods -n +oc get pods -n ``` ```bash NAME READY STATUS RESTARTS AGE -argocd-operator-controller-manager-6c449c6998-ts95w 2/2 Running 0 33s +gitops-operator-controller-manager-6c449c6998-ts95w 2/2 Running 0 33s ``` !!! info - If you see `Error: container's runAsUser breaks non-root policy`, means container wants to have admin privilege. run `oc adm policy add-scc-to-user privileged -z default -n argocd-operator-system` to enable admin on the namespace and change the following line in deployment resource: `runAsNonRoot: false`. This is a quick fix to make it running, this is not a suggested approach for *production*. + If you see `Error: container's runAsUser breaks non-root policy`, means container wants to have admin privilege. run `oc adm policy add-scc-to-user privileged -z default -n openshift-gitops-operator` to enable admin on the namespace and change the following line in deployment resource: `runAsNonRoot: false`. This is a quick fix to make it running, this is not a suggested approach for *production*. ## Usage @@ -115,7 +113,4 @@ including the namespace. make undeploy ``` - - [docs_usage]:../usage/basics.md -[olm_install]:olm.md#operator-install diff --git a/argocd-operator/docs/install/start.md b/argocd-operator/docs/install/start.md index e13305055cd..356eb26ce51 100644 --- a/argocd-operator/docs/install/start.md +++ b/argocd-operator/docs/install/start.md @@ -4,36 +4,12 @@ The Argo CD Operator was created with the intention of running through the [Oper specifically on [OpenShift 4][openshift_home]. This is where the operator shines most, as it leverages the powerful features built into the latest version of OpenShift. -That being said, the operator can be installed and provide the same functionality on any Kubernetes cluster. The -following methods are provided for installing the operator. - ## OpenShift The operator is published as part of the built-in Community Operators in the Operator Hub on OpenShift 4. See the -[OpenShift Install Guide][install_openshift] for more information on installing on the OpenShift platorm. - -## Operator Lifecycle Manager - -Using the Operator Lifecycle Manager to install and manage the Argo CD Operator is the preferred method. The operator -is published to [operatorhub.io][operatorhub_link]. Following the installation process there should work for most OLM -installations. - -Look at the [OLM Install Guide][install_olm] for an example using this approach with minikube. - -## Manual Installation +[OpenShift Install Guide][install_openshift] for more information on installing on the OpenShift platform. -The operator can be installed manually if desired. - -!!! info - The manual installation method requires cluster credentials that provide the `cluster-admin` ClusterRole or - equivalent. - -The [Manual Installation Guide][install_manual] provides the steps needed to manually install the operator on any -Kubernetes cluster. - -[install_manual]:./manual.md -[install_olm]:./olm.md [install_openshift]:./openshift.md [olm_home]:https://github.com/operator-framework/operator-lifecycle-manager [openshift_home]:https://try.openshift.com -[operatorhub_link]:https://operatorhub.io/operator/argocd-operator + diff --git a/argocd-operator/docs/proposals/001-proposal-template.md b/argocd-operator/docs/proposals/001-proposal-template.md deleted file mode 100644 index 6a934cdf1cb..00000000000 --- a/argocd-operator/docs/proposals/001-proposal-template.md +++ /dev/null @@ -1,92 +0,0 @@ -# [Proposal Title] - -This is the title of the enhancement. Keep it simple and descriptive. A good title can help -communicate what the enhancement is and should be considered as part of any review. - - -## Open Questions [optional] - -This is where to call out areas of the design that require closure before deciding to implement the design. - - -## Summary - -The `Summary` is required for producing accurate user-focused documentation -such as release notes or a development roadmap. It should be possible to collect this information -before implementation begins in order to avoid requiring implementers to split their attention -between writing release notes and implementing the feature itself. Before you get started with this document, -please feel free to have a conversation on this with the maintainers/community on Github that would help -drive a more organized thought process for the formal proposal here. - -## Motivation - -This section is for explicitly listing the motivation, goals and non-goals of this proposal. -Describe why the change is important and the benefits to users. - -### Goals - -List the specific goals of the proposal and their measurable results. How will we know that this has succeeded? - -### Non-Goals - -What is out of scope for this proposal? Listing non-goals helps to focus discussion and make -progress. - -## Proposal - -This is where we get down to details of what the proposal is about. - -### Use cases - -Add a list of detailed use cases this enhancement intends to take care of. - -#### Use case 1: -(Example) As a user, I would like to understand... - -#### Use case 2: -(Example) As a user, I would like to take an action on... - -### Implementation Details/Notes/Constraints [optional] - -What are the downsides to the implementation? What are some important details that didn't come across -above? Try to go into as much detail as necessary here. This might be a good place to talk about core -concepts and how they relate. - -You may have a work-in-progress Pull Request to demonstrate the functioning of the enhancement you are proposing. - -### Detailed examples - -### Security Considerations - -* How does this proposal impact the security aspects of argocd-operator? -* Are there any unresolved follow-ups that need to be done to make the enhancement more robust? - -### Risks and Mitigations - -What are the risks of this proposal and how do we mitigate them? - -For example, consider both security and how this will impact the larger argocd-operator ecosystem. - -Consider including folks that also work outside your immediate sub-project. - - -### Upgrade / Downgrade Strategy - -If applicable, how will the component be upgraded and downgraded? Make sure this is in the test -plan. - -Consider the following in developing an upgrade/downgrade strategy for this enhancement: - -- What changes (in invocations, configurations, API use, etc.) is an existing cluster required to - make upon upgrade in order to keep previous behavior? -- What changes (in invocations, configurations, API use, etc.) is an existing cluster required to - make upon upgrade in order to make use of the enhancement? - -## Drawbacks - -The idea is to find the best form of an argument why this enhancement should _not_ be implemented. - -## Alternatives - -Similar to the `Drawbacks` section, the `Alternatives` section is used to highlight and record other -possible approaches to delivering the value proposed by an enhancement. \ No newline at end of file diff --git a/argocd-operator/docs/proposals/002-controller-runtime-cache-transforms-for-secrets-and-configmaps.md b/argocd-operator/docs/proposals/002-controller-runtime-cache-transforms-for-secrets-and-configmaps.md deleted file mode 100644 index 3fbed022919..00000000000 --- a/argocd-operator/docs/proposals/002-controller-runtime-cache-transforms-for-secrets-and-configmaps.md +++ /dev/null @@ -1,89 +0,0 @@ -# Controller Runtime Cache Transform for Secrets and ConfigMaps - -This proposal outlines an approach to reduce memory consumed by the operator’s manager pod by stripping data fields from Secrets and ConfigMaps stored in controller-runtime’s cache when they are not tracked or required by the operator. - -## Problem - -We recently discovered that the Argo CD Operator consumes significantly more memory on large clusters, particularly those with a high number of Secrets and ConfigMaps. For example, in a test cluster with 2,000 Secrets and 2,000 ConfigMaps spread across 100 namespaces, the operator manager pod consumed over 2 GB of memory at peak, with just one Argo CD CR instance. - -Upon further investigation, we found that the primary contributor to this high memory usage is the underlying controller-runtime object cache, which the operator uses to watch resources. - -### Why Does This Happen? - -By default, controller-runtime caches all objects of a given type when **a watch is registered** for that type. - -For example, even if we add a watch only for Secrets owned by the operator: -```go -// Watch for changes to Secrets sub-resources owned by ArgoCD instances. -bldr.Owns(&v1.Secrets{}) -``` -controller-runtime will still cache **all Secrets in the cluster**, not just the operator-owned ones. This results in excessive memory usage on large clusters with many resources. - -Ideally, the operator should cache only the resources it needs. To achieve this optimization, we explored various caching options available in controller-runtime. - -## Proposed Solution - -At a high level, this proposal suggests: -- Use a labels to identify operator-owned/tracked/required resources. -- Strip unnecessary fields from non-operator objects before storing them in the controller-runtime cache. -- Introduce a self-healing mechanism that automatically labels resources of interest that initially lack the label, ensuring they are cached in full going forward. - -### Implementation - -1. Cache Transform - Apply a transform on Secrets and ConfigMaps: - - For non-operator objects, strip heavy fields (data, stringData, binaryData). - - For operator-tracked objects (identified by labels like `operator.argoproj.io/tracked-by`, `argocd.argoproj.io/secret-type`), retain full content. - - This reduces memory footprint by storing only metadata for irrelevant objects. - -2. Client Wrapper - Introduce a wrapper around the cached client: - - On `Get`, if an object looks “stripped” (heuristic: `Data == nil` etc.) or missing required labels → fallback to live client. - - After a successful live fetch, patch a tracking label so the cache retains the full object in future updates. - - Errors while patching are non-fatal: subsequent reconciles will retry or fallback to live again. - -3. Integration - - Wire transforms into `main.go` via `cache.Options.ByObject`. - - Update reconcilers to use the wrapped client for transparent fallback handling. - -### Benefits - -- **Reduced memory usage:** Only operator-relevant Secrets/ConfigMaps are cached with full data. -- **Correctness preserved:** Fallback ensures reconciles always see full objects when needed. -- **Self-healing:** Once an object is accessed, it is labeled and cached fully, avoiding repeated live GETs. - -## Proof-of-Concept (PoC) Results - -These metrics were collected from a test cluster containing **100 ConfigMaps** and **100 Secrets**, each approximately **1 MB** in size. The cluster was running four Argo CD instances and no other workload operators. - -With the optimization enabled, operator memory usage dropped from **~350 MB** to **~100 MB**. - -UnOptimized Operator Manager Memory: - -![UnOptimized Operator Manager](assets/unoptimized-manager-memory.png) - -Optimized Operator Manager Memory: - -![Optimized Operator Manager](assets/optimized-manager-memory.png) - -However, we could not reduce the startup memory consumption, which remained at **~750 MB** in both cases. - -We previously attempted another approach in [#1795](https://github.com/argoproj-labs/argocd-operator/pull/1795), but it introduced significant complexity and restricted how watches could be set up. Compared to that, this solution provides a better balance between complexity, maintenance overhead, and outcome. - -## Trade-offs / Risks and Mitigations - -1. Extra API calls - - When a resource is stripped in the cache, the operator performs a live lookup. - - For resources that the operator cares about and are missing the label, this happens only once per resource, since the label is added for future caching. - - Legitimately empty objects may trigger extra live GETs, but this is rare. - -2. External resource labeling - - The operator supports referencing external ConfigMaps and Secrets in the Argo CD CR. - - These resources will be labelled. However, adding labels for operator tracking is a widely accepted practice within the Kubernetes community. - - Additionally, we can provide a feature flag to disable this optimization for users who prefer not to mutate external resources. - -## Future scope - -- Add metrics for cache hits vs. live fallbacks to measure effectiveness. -- Extend this approach to other resource types once proven stable. \ No newline at end of file diff --git a/argocd-operator/docs/proposals/assets/optimized-manager-memory.png b/argocd-operator/docs/proposals/assets/optimized-manager-memory.png deleted file mode 100644 index ce93e3211bf..00000000000 Binary files a/argocd-operator/docs/proposals/assets/optimized-manager-memory.png and /dev/null differ diff --git a/argocd-operator/docs/proposals/assets/unoptimized-manager-memory.png b/argocd-operator/docs/proposals/assets/unoptimized-manager-memory.png deleted file mode 100644 index 2c56863905c..00000000000 Binary files a/argocd-operator/docs/proposals/assets/unoptimized-manager-memory.png and /dev/null differ diff --git a/argocd-operator/docs/reference/argocdexport.md b/argocd-operator/docs/reference/argocdexport.md deleted file mode 100644 index b68628e10c9..00000000000 --- a/argocd-operator/docs/reference/argocdexport.md +++ /dev/null @@ -1,120 +0,0 @@ -# ArgoCDExport - -The `ArgoCDExport` resource is a Kubernetes Custom Resource (CRD) that describes the desired state for the export of a given -Argo CD cluster and enables disaster recovery for the components that make up Argo CD. - -When the Argo CD Operator sees a new ArgoCDExport resource, the operator manages the built-in Argo CD export process. - -The ArgoCDExport Custom Resource consists of the following properties. - -Name | Default | Description ---- | --- | --- -[**Argocd**](#argocd) | [Empty] | The name of an ArgoCD instance to export. -[**Image**](#image) | `quay.io/jmckind/argocd-operator-util` | The container image for the export Job. -[**Schedule**](#schedule) | [Empty] | Export schedule in Cron format, see https://en.wikipedia.org/wiki/Cron. -[**Storage**](#storage-options) | [Object] | The storage configuration options. -[**Version**](#version) | v0.0.15 (SHA) | The tag to use with the container image for the export Job. - -## Argocd - -The name of an ArgoCD instance to export. - -### Argocd Example - -The following example sets the name of an ArgoCD resource to export. - -``` yaml -apiVersion: argoproj.io/v1alpha1 -kind: ArgoCDExport -metadata: - name: example-argocdexport - labels: - example: argocd -spec: - argocd: example-argocd -``` - -## Image - -The container image for the export Job. - -### Image Example - -The following example sets the default value using the `Image` property on the `ArgoCDExport` resource. - -``` yaml -apiVersion: argoproj.io/v1alpha1 -kind: ArgoCDExport -metadata: - name: example-argocdexport - labels: - example: image -spec: - image: quay.io/jmckind/argocd-operator-util -``` - -## Schedule - -The export schedule in Cron format, see https://en.wikipedia.org/wiki/Cron. - -### Schedule Example - -The following example sets a recurring export schedule that runs daily at midnight. - -``` yaml -apiVersion: argoproj.io/v1alpha1 -kind: ArgoCDExport -metadata: - name: example-argocdexport - labels: - example: schedule -spec: - schedule: "0 0 * * *" -``` - -## Storage Options - -The following properties are available for configuring the storage for the export data. - -Name | Default | Description ---- | --- | --- -Backend | `local` | The storage backend to use, must be "local", "aws", "azure" or "gcp". -PVC | [Object] | The [PersistentVolumeClaimSpec](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.17/#persistentvolumeclaimspec-v1-core) specifying the desired characteristics for a PersistentVolumeClaim. -SecretName | [Export Name] | The name of a Secret with encryption key, credentials, etc. - -### Storage Example - -The following example sets the default values using the `Storage` property on the `ArgoCDExport` resource. - -``` yaml -apiVersion: argoproj.io/v1alpha1 -kind: ArgoCDExport -metadata: - name: example-argocdexport - labels: - example: storage -spec: - storage: - backend: local - pvc: {} - secretName: example-argocdexport -``` - -## Version - -The tag to use with the container image for all Argo CD components. - -### Version Example - -The following example sets the default value using the `Version` property on the `ArgoCDExport` resource. - -``` yaml -apiVersion: argoproj.io/v1alpha1 -kind: ArgoCDExport -metadata: - name: example-argocdexport - labels: - example: version -spec: - version: v0.0.15 -``` diff --git a/argocd-operator/docs/release-process.md b/argocd-operator/docs/release-process.md deleted file mode 100644 index 1682a648a5b..00000000000 --- a/argocd-operator/docs/release-process.md +++ /dev/null @@ -1,167 +0,0 @@ -# Argo CD Operator Release Process - -!!! note - - Currently argocd-operator can only support releasing versions which are the next highest release. Z-stream releases for minor versions which are not the highest minor version are not possible at this time. This functionality will be possible once argocd-operator switches from a single subscription channel (currently "alpha") model to release-based subscription channels, as [this GitHub issue](https://github.com/argoproj-labs/argocd-operator/issues/1436) explains. - -## Prerequisites - -Before beginning, make sure you have push access to the following repositories in quay.io: - - * [https://quay.io/argoprojlabs/argocd-operator-util](https://quay.io/argoprojlabs/argocd-operator-util) - * [http://quay.io/argoprojlabs/argocd-operator](http://quay.io/argoprojlabs/argocd-operator) - * [http://quay.io/argoprojlabs/argocd-operator-registry](http://quay.io/argoprojlabs/argocd-operator-registry) - -Lastly, make sure you are listed as a maintainer for argocd-operator in order to tag and publish releases. - -## `argocd-operator` changes - -* `VERSION` in Makefile defines the project version for the bundle. You will need to update this value when you want to upgrade the version of your project. - -```txt - VERSION ?= 0.2.0 -``` - -* Ensure that the `replaces` field in `config/manifests/bases/argocd-operator.clusterserviceversion.yaml` is set to the version you are planning to release. - -* Ensure that the `currentCSV` field in `deploy/olm-catalog/argocd-operator/argocd-operator.package.yaml` is set to the version you are planning to release. - -* Build the `argocd-operator-util` image. - -```txt - make util-build -``` - -* Push the `argocd-operator-util` image to quay.io - -```txt - make util-push -``` - -* Copy the SHA digest of utility container image from the above command. Set this value to `ArgoCDDefaultExportJobVersion` in `common/defaults.go`. - -* Build the operator container image. (Below command assumes the release version as `v0.2.0`; please change the command accordingly.) - -```txt - make docker-build IMG=quay.io/argoprojlabs/argocd-operator:v0.2.0-rc1 -``` - -* Push the operator container image. (Below command assumes the release version as `v0.2.0`; please change the command accordingly.) - -```txt - make docker-push IMG=quay.io/argoprojlabs/argocd-operator:v0.2.0-rc1 -``` - -* Create the bundle artifacts using the SHA of the operator container image. - -```txt - make bundle IMG=quay.io/argoprojlabs/argocd-operator@sha256:d894c0f7510c8f41b48900b52eac94f623885fd409ebf2660793cd921b137bde -``` - -* The step above will create some changes to the control-plane code that must be reverted: - * In `bundle/manifests/argocd-operator.clusterserviceversion.yaml` and in `deploy/olm-catalog/argocd-operator/[your-version]/argocd-operator.[your-version].clusterserviceversion.yaml`, under the `spec.install.spec.deployments` add the control-plane label and change the deployment `spec.selector.matchLabels.control-plane` from `argocd-operator` to `controller-manager`, like so: -```yaml -deployments: - - label: - control-plane: controller-manager - name: argocd-operator-controller-manager - spec: - replicas: 1 - selector: - matchLabels: - control-plane: controller-manager - strategy: {} - template: - metadata: - labels: - control-plane: controller-manager -``` - * In `bundle/manifests/argocd-operator-controller-manager-metrics-service_v1_service.yaml` and `deploy/olm-catalog/argocd-operator/[your-version]/argocd-operator-controller-manager-metrics-service_v1_service.yaml`, update the control-plane labels from `argocd-operator ` to `controller-manager`, like so: - -```yaml -metadata: - creationTimestamp: null - labels: - control-plane: controller-manager - name: argocd-operator-controller-manager-metrics-service -spec: - ports: - - name: https - port: 8443 - targetPort: 8443 - selector: - control-plane: controller-manager -``` - * In `bundle/manifests/argocd-operator-webhook-service_v1_service.yaml` and `deploy/olm-catalog/argocd-operator/[your-version]/argocd-operator-webhook-service_v1_service.yaml`, update the control-plane label from `argocd-operator` to `controller-manager`, like so: -```yaml -selector: - control-plane: controller-manager -``` - -* Create the registry image. (Below command assumes the release version as `v0.2.0`; please change the command accordingly.) - -```txt - make registry-build REGISTRY_IMG=quay.io/argoprojlabs/argocd-operator-registry:v0.2.0-rc1 -``` - -* Push the registry image. (Below command assumes the release version as `v0.2.0`; please change the command accordingly.) - -```txt - make registry-push REGISTRY_IMG=quay.io/argoprojlabs/argocd-operator-registry:v0.2.0-rc1 -``` - -* Update `deploy/catalog_source.yaml` with the SHA of the operator registry image. - -* Once all testing has been done, from the quay.io user interface, add the actual release tags (e.g. 'v0.2.0') to the `argocd-operator` and `argocd-operator-registry` images. - -* Commit and push the changes, then create a PR and get it merged. - -* Go to the argocd-operator GitHub repo and [create (aka draft) a new release](https://github.com/argoproj-labs/argocd-operator/releases). Make sure to include release notes detailing what's changed and contributors. GitHub can help you generate new release notes (make sure to only include changes since the previous release, there is a dropdown option on the GitHub UI when drafting release notes to specify the previous tag). - ----- - -## Steps to create a PR for Kubernetes OperatorHub Community Operators - -* Fork and clone [kubernetes community operators](https://github.com/k8s-operatorhub/community-operators). - -* Go to the `community-operators/operators/argocd-operator` folder. - -* Create a new folder for the release with two child folders inside of it; one called `manifests` and one called `metadata`. - -* In the `manifests` folder, copy and paste the files from the actual argocd-operator's `deploy/olm-catalog/argocd-operator/[release-version]` folder. - -* Also in the `manifests` folder, edit the CSV file to add a `containerImage` tag to the metadata section. Copy the value from the `image` tag already found in the file. - -* In the `metadata` folder, create a file called `annotations.yaml`. The content of this file can be copied from the previous argocd-operator release version in this repository. - -* Commit, sign and push the changes, then create a PR. The PR merge process should be automatic if all the checks pass; once the PR is merged then continue on to the next step. - ----- - -## Steps to create a PR for Red Hat Operators - -* Fork and clone [redhat community operators](https://github.com/redhat-openshift-ecosystem/community-operators-prod). - -* Go to the `community-operators-prod/operators/argocd-operator` folder. - -* Create a new folder for the release with two child folders inside of it; one called `manifests` and one called `metadata`. - -* In the `manifests` folder, copy and paste the files from the actual argocd-operator's `deploy/olm-catalog/argocd-operator/[release-version]` folder. - -* Also in the `manifests` folder, edit the CSV file to add a `containerImage` tag to the metadata section. Copy the value from the `image` tag already found in the file. - -* In the `metadata` folder, create a file called `annotations.yaml`. The content of this file can be copied from the previous argocd-operator release version in this repository. - -* Commit, sign and push the changes, then create a PR. The PR process should be automatic for this repository as well if all the checks pass. - -## Synchonizing changes back to master branch and setting up the next version - -* In the `argocd-operator` repo, you have to synchronize the changes from the release branch back to the master branch. After doing this run `make bundle`. (Note: this will revert some of the changes you made earlier, but this is okay for the master branch. Without running `make bundle` the tests will not pass, and ignoring those and merging regardless will make all future PR's also fail.) - -* Update the `VERSION` in the Makefile in the `argocd-operator` repo's master branch to the next version (e.g. from `0.2.0 to 0.3.0). - -* In `config/manifests/bases/argocd-operator.clusterserviceversion.yaml`, update the `replaces:` field to be the current version (the one you just released), and the `version:` field to be the next version. - -* Run `make bundle` again to generate the initial bundle manifests for the next version. (You may need to also run `go mod vendor` and `go mod tidy`) - -* Commit and push the changes, then create a PR to argocd-operator's master branch. diff --git a/argocd-operator/docs/upgrading.md b/argocd-operator/docs/upgrading.md index d7631803846..388d68e9764 100644 --- a/argocd-operator/docs/upgrading.md +++ b/argocd-operator/docs/upgrading.md @@ -194,4 +194,4 @@ references declared on **`spec.webhookSecrets`** in the **ArgoCD** CR (`v1beta1` - **If you do not set** `spec.webhookSecrets`, the operator continues to omit declarative webhook management; **`webhook.*` keys already present in `argocd-secret` are left as-is**, including values you patched in manually before this feature existed. - **If you set** `spec.webhookSecrets`, the operator syncs the providers you declare into `argocd-secret`. Providers not listed while management is enabled can have their **`webhook.*` keys cleared** on reconcile—see [Configuring webhook secrets](./usage/webhook-secrets.md) for exact semantics. -For migration from manual edits, verification, integrations (External Secrets, Sealed Secrets), and troubleshooting, use the **[Configuring webhook secrets](./usage/webhook-secrets.md)** guide. A runnable example can be found at . \ No newline at end of file +For migration from manual edits, verification, integrations (External Secrets, Sealed Secrets), and troubleshooting, use the **[Configuring webhook secrets](./usage/webhook-secrets.md)** guide. A runnable example can be found at . \ No newline at end of file diff --git a/argocd-operator/docs/usage/basics.md b/argocd-operator/docs/usage/basics.md index d7c15f744d5..8a480c5a744 100644 --- a/argocd-operator/docs/usage/basics.md +++ b/argocd-operator/docs/usage/basics.md @@ -1,6 +1,6 @@ # Usage Basics -See the [ArgoCD Reference][argocd_reference] for the full list of properties and defaults to configure the Argo CD cluster. +See the [ArgoCD CRD Reference][argocd_reference] for the full list of properties and defaults to configure the Argo CD cluster. The following example shows the most minimal valid manifest to create a new Argo CD cluster with the default configuration. @@ -214,14 +214,14 @@ The Argo CD instance created above can also be used to manage the cluster scoped apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: - name: argocd-operator + name: gitops-operator spec: config: env: - name: ARGOCD_CLUSTER_CONFIG_NAMESPACES value: channel: alpha - name: argocd-operator + name: gitops-operator source: argocd-catalog sourceNamespace: olm ``` diff --git a/argocd-operator/docs/usage/custom_roles.md b/argocd-operator/docs/usage/custom_roles.md index 102de533e4f..75a0f788d7d 100644 --- a/argocd-operator/docs/usage/custom_roles.md +++ b/argocd-operator/docs/usage/custom_roles.md @@ -8,7 +8,7 @@ Example: Custom role environment variables in operator Subscription: apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: - name: argocd-operator + name: gitops-operator namespace: argocd spec: config: @@ -25,7 +25,7 @@ Example: Custom role environment variables in operator Deployment: kind: Deployment apiVersion: apps/v1 metadata: - name: argocd-operator-controller-manager + name: gitops-operator-controller-manager namespace: argocd spec: replicas: 1 diff --git a/argocd-operator/docs/usage/environment_variables.md b/argocd-operator/docs/usage/environment_variables.md index 22efbcadc0e..4369a8ef51f 100644 --- a/argocd-operator/docs/usage/environment_variables.md +++ b/argocd-operator/docs/usage/environment_variables.md @@ -1,6 +1,6 @@ # Environment Variables -The following environment variables are available in `argocd-operator`: +The following environment variables are available in GitOps Operator: | Environment Variable | Default Value | Description | | --- | --- | --- | @@ -11,7 +11,7 @@ The following environment variables are available in `argocd-operator`: | `PROMOTER_CONTROLLER_CLUSTER_ROLE` | none | Administrators can configure a common cluster role for all the managed namespaces in role bindings for the GitOps Promoter Controller with this environment variable. Note: If this environment variable contains custom roles, the Operator doesn’t create the default admin role. Instead, it uses the existing custom role for all managed namespaces. | | `PROMOTER_API_SERVER_CLUSTER_ROLE` | none | Administrators can configure a common cluster role for all the managed namespaces in role bindings for the GitOps Promoter API Server with this environment variable. Note: If this environment variable contains custom roles, the Operator doesn’t create the default admin role. Instead, it uses the existing custom role for all managed namespaces. | | `REMOVE_MANAGED_BY_LABEL_ON_ARGOCD_DELETION` | false | When an Argo CD instance is deleted, namespaces managed by that instance (via the `argocd.argoproj.io/managed-by` label ) will retain the label by default. Users can change this behavior by setting the environment variable `REMOVE_MANAGED_BY_LABEL_ON_ARGOCD_DELETION` to `true` in the Subscription. | -| `ARGOCD_LABEL_SELECTOR` | none | The label selector can be set on argocd-opertor by exporting `ARGOCD_LABEL_SELECTOR` (eg: `export ARGOCD_LABEL_SELECTOR=foo=bar`). The labels can be added to the argocd instances using the command `kubectl label argocd test1 foo=bar -n test-argocd`. This will enable the operator instance to be tailored to oversee only the corresponding ArgoCD instances having the matching label selector. | +| `ARGOCD_LABEL_SELECTOR` | none | The label selector can be set on gitops-operator by exporting `ARGOCD_LABEL_SELECTOR` (eg: `export ARGOCD_LABEL_SELECTOR=foo=bar`). The labels can be added to the argocd instances using the command `kubectl label argocd test1 foo=bar -n test-argocd`. This will enable the operator instance to be tailored to oversee only the corresponding ArgoCD instances having the matching label selector. | | `LOG_LEVEL` | info | This sets the logging level of the manager (operator) pod. Valid values are "debug", "info", "warn", "error", "panic" and "fatal". | | `MEMORY_OPTIMIZATION_ENABLED` | true | When set to `false`, disables the memory optimization that strips data from Secrets and ConfigMaps that are not tracked by the operator. This optimization helps reduce memory usage. | diff --git a/argocd-operator/docs/usage/export.md b/argocd-operator/docs/usage/export.md deleted file mode 100644 index b4e295c7491..00000000000 --- a/argocd-operator/docs/usage/export.md +++ /dev/null @@ -1,509 +0,0 @@ -# Export - -ArgoCDExport functionality can export details of managed application periodically, facilitating operations tasks such as backups or migrations. -The data consists of a series of Kubernetes manifests representing the various cluster resources in YAML format stored in a single file. -This exported YAML file is then `AES` encrypted before being saved to the storage backend of choice. - -See the Argo CD [Disaster Recovery][argocd_dr] documentation for more information on the Argo CD recovery procedure. - -See the [ArgoCDExport Reference][argocdexport_reference] for the full list of properties to configure the export process. - -## Requirements - -The following sections assume that an existing Argo CD cluster named `example-argocd` has been deployed by the operator using the existing basic `ArgoCD` example. - -``` bash -kubectl apply -f examples/argocd-basic.yaml -``` - -If an `ArgoCDExport` resource is created that references an Argo CD cluster that does not exist, the operator will simply move on and wait until the Argo CD cluster does exist before taking any further action in the export process. - -## ArgoCDExport - -The following example shows the most minimal valid manifest to export (backup) an Argo CD cluster that was provisioned using the Argo CD Operator. - -``` yaml -apiVersion: argoproj.io/v1alpha1 -kind: ArgoCDExport -metadata: - name: example-argocdexport - labels: - example: basic -spec: - argocd: example-argocd -``` - -This would create a new `ArgoCDExport` resource with the name of `example-argocdexport`. The operator will provision a -Kubernetes Job to run the built-in Argo CD export utility on the specified Argo CD cluster. - -If the `Schedule` property was set using valid Cron syntax, the operator will provision a CronJob to run the export on -a recurring schedule. Each time the CronJob executes, the export data will be overritten by the operator, only keeping -the most recent version. - -The data that is exported by the Job is owned by the `ArgoCDExport` resource, not the Argo CD cluster. So the cluster can -come and go, starting up everytime by importing the same backup data, if desired. - -See the `ArgoCD` [Import Reference][argocd_import] documentation for more information on importing the backup data when starting a new -Argo CD cluster. - -## Export Secrets - -An export Secret is used by the operator to hold the backup encryption key, as well as credentials if using a cloud -provider storage backend. The operator will create the Secret if it does not already exist, using the naming convention -`[EXPORT NAME]-export`. For example, if the `ArgoCDExport` resource is named `example-argocdexport` from above, the -name of the generated secret would be `example-argocdexport-export`. - -The `SecretName` property on the `ArgoCDExport` Storage Spec can be used to change the name of the Secret. - -``` yaml -apiVersion: argoproj.io/v1alpha1 -kind: ArgoCDExport -metadata: - name: example-argocdexport - labels: - example: secret-name -spec: - argocd: example-argocd - storage: - secretName: my-backup-secret -``` - -The following property is common across all storage backends. See the sections below for additional properties that are -required for the different cloud provider backends. - -**backup.key** - -The `backup.key` is the encryption key used by the operator when encrypting or decrypting the exported data. This key -will be generated automatically if not provided. - -## Storage Backend - -The exported data can be saved on a variety of backend storage locations. This can be persisted locally in the -Kubernetes cluster or remotely using a cloud provider. - -See the `ArgoCDExport` [Storage Reference][storage_reference] for information on controlling the underlying storage -options. - -### Local - -By default, the operator will use a `local` storage backend for the export process. The operator will provision a -PersistentVolumeClaim using the defaults below to store the export data locally in the cluster on a PersistentVolume. - -``` yaml -apiVersion: argoproj.io/v1alpha1 -kind: ArgoCDExport -metadata: - name: example-argocdexport - labels: - example: pvc -spec: - argocd: example-argocd - storage: - backend: local - pvc: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 2Gi - storageClassName: standard -``` - -#### Local Example - -Create an `ArgoCDExport` resource in the `argocd` namespace using the basic example. - -``` bash -kubectl apply -n argocd -f examples/argocdexport-basic.yaml -``` - -You can view the list of `ArgoCDExport` resources. - -``` bash -kubectl get argocdexports -``` -``` -NAME AGE -example-argocdexport 15m -``` - -Creating the resource will result in the operator provisioning a Kubernetes Job to perform the export process. The Job -should not take long to complete. - -``` bash -kubectl get pods -l job-name=example-argocdexport -``` -``` -NAME READY STATUS RESTARTS AGE -example-argocdexport-q92qm 0/1 Completed 0 1m -``` - -if the Job fails for some reason, view the logs of the Pod to help in troubleshooting. - -``` bash -kubectl logs example-argocdexport-q92qm -``` - -Output similar to what is shown below indicates a successful export. - -``` -exporting argo-cd -creating argo-cd backup -encrypting argo-cd backup -argo-cd export complete -``` - -View the PersistentVolumeClaim created by the operator for the export data. - -``` bash -kubectl get pvc -n argocd -``` -``` -NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE -example-argocdexport Bound pvc-6d15143d-184a-4e5a-a185-6b86924af8bd 2Gi RWO gp2 39s -``` - -There should also be a corresponding PersistentVolume if dynamic volume support is enabled on the Kubernetes cluster. - -``` bash -kubectl get pv -n argocd -``` -``` -NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE -pvc-6d15143d-184a-4e5a-a185-6b86924af8bd 2Gi RWO Delete Bound argocd/example-argocdexport gp2 34s -``` - -### AWS - -The operator can use an Amazon Web Services S3 bucket to store the export data. - -``` yaml -apiVersion: argoproj.io/v1alpha1 -kind: ArgoCDExport -metadata: - name: example-argocdexport - labels: - example: aws -spec: - argocd: example-argocd - storage: - backend: aws - secretName: aws-backup-secret -``` - -#### AWS Secrets - -The storage `SecretName` property should reference an existing secret that contains the AWS credentials and bucket information. - -``` yaml -apiVersion: v1 -kind: Secret -metadata: - name: aws-backup-secret - labels: - example: aws -type: Opaque -data: - aws.bucket.name: ... - aws.bucket.region: ... - aws.access.key.id: ... - aws.secret.access.key: .... -``` - -The following properties must exist on the Secret referenced in the `ArgoCDExport` resource when using `aws` as the storage backend. - -**aws.bucket.name** - -The name of the AWS S3 bucket. This should be the name of the bucket only, do not prefix the value `s3://`, as the operator will handle this automatically. - -**aws.bucket.region** - -The region of the AWS S3 bucket. - -**aws.access.key.id** - -The AWS IAM Access Key ID. - -**aws.secret.access.key** - -The AWS IAM Secret Access Key. - -#### AWS Example - -Once the required AWS credentials are set on the export Secret, create the `ArgoCDExport` resource in the `argocd` -namespace using the included AWS example. - -``` bash -kubectl apply -n argocd -f examples/argocdexport-aws.yaml -``` - -Creating the resource will result in the operator provisioning a Kubernetes Job to perform the export process. - -``` bash -kubectl get pods -l job-name=example-argocdexport -``` - -The Job should not take long to complete. - -``` -NAME READY STATUS RESTARTS AGE -example-argocdexport-q92qm 0/1 Completed 0 1m -``` - -If the Job fails for some reason, view the logs of the Pod to help in troubleshooting. - -``` bash -kubectl logs example-argocdexport-q92qm -``` - -Output similar to what is shown below indicates a successful export. - -``` -exporting argo-cd -creating argo-cd backup -encrypting argo-cd backup -pushing argo-cd backup to aws -make_bucket: example-argocdexport -upload: ../../backups/argocd-backup.yaml to s3://example-argocdexport/argocd-backup.yaml -argo-cd export complete -``` - -#### AWS IAM Configuration - -TODO: Add the required Role and Service Account configuration needed through AWS. - -### Azure - -The operator can use a Micosoft Azure Storage Container to store the export data as Blob. - -``` yaml -apiVersion: argoproj.io/v1alpha1 -kind: ArgoCDExport -metadata: - name: example-argocdexport - labels: - example: azure -spec: - argocd: example-argocd - storage: - backend: azure - secretName: azure-backup-secret -``` - -#### Azure Secrets - -The storage `SecretName` property should reference an existing secret that contains the Azure credentials and bucket information. - -``` yaml -apiVersion: v1 -kind: Secret -metadata: - name: azure-backup-secret - labels: - example: azure -type: Opaque -data: - azure.container.name: ... - azure.service.id: ... - azure.service.cert: | - ... - azure.storage.account: ... - azure.tenant.id: ... -``` - -The following properties must exist on the Secret referenced in the `ArgoCDExport` resource when using `azure` as the storage backend. - -**azure.container.name** - -The name of the Azure Storage Container. This should be the name of the container only. If the container does not -already exist, the operator will attempt to create it. - -**azure.service.id** - -The ID for the Service Principal that will be used to access Azure Storage. - -**azure.service.cert** - -The combination of certificate and private key for authenticating the Service Principal that will be used to access Azure Storage. - -**azure.storage.account** - -The name of the Azure Storage Account that owns the Container. - -**azure.tenant.id** - -The ID for the Azure Tenant that owns the Service Principal. - -#### Azure Example - -Once the required Azure credentials are set on the export Secret, create the `ArgoCDExport` resource in the `argocd` -namespace using the included AWS example. - -``` bash -kubectl apply -n argocd -f examples/argocdexport-azure.yaml -``` - -Creating the resource will result in the operator provisioning a Kubernetes Job to perform the export process. - -``` bash -kubectl get pods -l job-name=example-argocdexport -``` - -The Job should not take long to complete. - -``` -NAME READY STATUS RESTARTS AGE -example-argocdexport-q92qm 0/1 Completed 0 1m -``` - -If the Job fails for some reason, view the logs of the Pod to help in troubleshooting. - -``` bash -kubectl logs example-argocdexport-q92qm -``` - -Output similar to what is shown below indicates a successful export. - -``` -exporting argo-cd -creating argo-cd backup -encrypting argo-cd backup -pushing argo-cd backup to azure -[ - { - "cloudName": "...", - "homeTenantId": "...", - "id": "...", - "isDefault": true, - "managedByTenants": [], - "name": "...", - "state": "Enabled", - "tenantId": "...", - "user": { - "name": "...", - "type": "servicePrincipal" - } - } -] -{ - "created": false -} -Finished[#############################################################] 100.0000% -{ - "etag": "\"0x000000000000000\"", - "lastModified": "2020-04-20T16:20:00+00:00" -} -argo-cd export complete -``` - -#### Azure AD Configuration - -TODO: Add the required Role and Service Account configuration needed through Azure Active Directory. - -### GCP - -The operator can use a Google Cloud Storage bucket to store the export data. - -``` yaml -apiVersion: argoproj.io/v1alpha1 -kind: ArgoCDExport -metadata: - name: example-argocdexport - labels: - example: gcp -spec: - argocd: example-argocd - storage: - backend: gcp - secretName: gcp-backup-secret -``` - -#### GCP Secrets - -The storage `SecretName` property should reference an existing secret that contains the GCP credentials and bucket information. - -``` yaml -apiVersion: v1 -kind: Secret -metadata: - name: gcp-backup-secret - labels: - example: gcp -type: Opaque -data: - gcp.bucket.name: ... - gcp.project.id: ... - gcp.key.file: | - ... -``` - -The following properties must exist on the Secret referenced in the `ArgoCDExport` resource when using `gcp` as the storage backend. - -**gcp.bucket.name** - -The name of the GCP storage bucket. This should be the name of the bucket only, do not prefix the value `gs://`, as the operator will handle this automatically. - -**gcp.project.id** - -The the project ID to use for authenticating with GCP. This can be the text name or numeric ID for the GCP project. - -**gcp.key.file** - -The GCP key file that contains the service account authentication credentials. The key file can be JSON formatted (preferred) or p12 (legacy) format. - -#### GCP Example - -Once the required GCP credentials are set on the export Secret, create the `ArgoCDExport` resource in the `argocd` -namespace using the included GCP example. - -``` bash -kubectl apply -f examples/argocdexport-gcp.yaml -``` - -This will result in the operator creating a Job to perform the export process. - -``` bash -kubectl get pods -l job-name=example-argocdexport -``` - -The Job should not take long to complete. - -``` -NAME READY STATUS RESTARTS AGE -example-argocdexport-q92qm 0/1 Completed 0 1m -``` - -If the Job fails for some reason, view the logs of the Pod to help in troubleshooting. - -``` bash -kubectl logs example-argocdexport-q92qm -``` - -Output similar to what is shown below indicates a successful export. - -``` -exporting argo-cd -creating argo-cd backup -encrypting argo-cd backup -pushing argo-cd backup to gcp -Activated service account credentials for: [argocd-export@example-project.iam.gserviceaccount.com] -Creating gs://example-argocdexport/... -Copying file:///backups/argocd-backup.yaml [Content-Type=application/octet-stream]... -/ [1 files][ 7.8 KiB/ 7.8 KiB] -Operation completed over 1 objects/7.8 KiB. -argo-cd export complete -``` - -#### GCP IAM Configuration - -TODO: Add the required Role and Service Account configuration needed through GCP. - -## Import - -See the `ArgoCD` [Import Reference][argocd_import] documentation for more information on importing the backup data when starting a new -Argo CD cluster. - -[argocdexport_reference]:../reference/argocdexport.md -[storage_reference]:../reference/argocdexport.md#storage-options -[argocd_dr]:https://argoproj.github.io/argo-cd/operator-manual/disaster_recovery/ -[argocd_import]:../reference/argocd.md#import-options diff --git a/argocd-operator/docs/usage/gitops-promoter.md b/argocd-operator/docs/usage/gitops-promoter.md index 80f90030403..3a632b0c732 100644 --- a/argocd-operator/docs/usage/gitops-promoter.md +++ b/argocd-operator/docs/usage/gitops-promoter.md @@ -1,7 +1,7 @@ # GitOps Promoter The [GitOps Promoter](https://gitops-promoter.readthedocs.io/) can be deployed as an optional workload through cluster-scoped instances reconciled by the Argo CD operator. -This allows for environment promotion for GitOps via the rendered manifests pattern. This pattern can be accomplished by using Argo CD's [Source Hydrator](https://argocd-operator.readthedocs.io/en/latest/reference/argocd/#source-hydrator-options). +This allows for environment promotion for GitOps via the rendered manifests pattern. This pattern can be accomplished by using Argo CD's [Source Hydrator](https://gitops-operator.readthedocs.io/en/latest/reference/argocd/#source-hydrator-options). ## Installation diff --git a/argocd-operator/docs/usage/image-updater.md b/argocd-operator/docs/usage/image-updater.md index 42e7122195b..93e42d46eb4 100644 --- a/argocd-operator/docs/usage/image-updater.md +++ b/argocd-operator/docs/usage/image-updater.md @@ -28,7 +28,7 @@ The operator supports two installation modes: The controller runs in the same namespace as the Argo CD instance and watches only that namespace. This is the default behavior when `IMAGE_UPDATER_WATCH_NAMESPACES` is not set or is empty. -If you use Argo CD's [Applications in any namespace](https://argocd-operator.readthedocs.io/en/latest/usage/apps-in-any-namespace/) feature and have `Application` resources in additional namespaces, you can specify a comma-separated list of namespaces to watch: +If you use Argo CD's [Applications in any namespace](https://gitops-operator.readthedocs.io/en/latest/usage/apps-in-any-namespace/) feature and have `Application` resources in additional namespaces, you can specify a comma-separated list of namespaces to watch: ``` yaml spec: diff --git a/argocd-operator/docs/usage/imagepullpolicy-configuration.md b/argocd-operator/docs/usage/imagepullpolicy-configuration.md index 68cb46f3be3..68c57ce142e 100644 --- a/argocd-operator/docs/usage/imagepullpolicy-configuration.md +++ b/argocd-operator/docs/usage/imagepullpolicy-configuration.md @@ -33,15 +33,15 @@ export IMAGE_PULL_POLICY=IfNotPresent apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: - name: argocd-operator + name: gitops-operator spec: config: env: - name: IMAGE_PULL_POLICY value: "IfNotPresent" channel: alpha - name: argocd-operator - source: argocd-catalog + name: gitops-operator + source: gitops-catalog sourceNamespace: olm ``` @@ -51,8 +51,8 @@ spec: apiVersion: apps/v1 kind: Deployment metadata: - name: argocd-operator-controller-manager - namespace: argocd-operator-system + name: gitops-operator-controller-manager + namespace: openshift-gitops-operator spec: template: spec: diff --git a/argocd-operator/docs/usage/ingress.md b/argocd-operator/docs/usage/ingress.md index 4781516d7a2..5cc230d9200 100644 --- a/argocd-operator/docs/usage/ingress.md +++ b/argocd-operator/docs/usage/ingress.md @@ -4,8 +4,6 @@ The Argo CD Operator offers support for managing Ingress resources to access the ## Cluster -This guide builds on the [OLM Install Guide][install_olm] and assumes a Kubernetes cluster based on [minikube](https://minikube.sigs.k8s.io/). - ### Ingress Controller Ensure that the `ingress` addon is enabled for the minikube cluster. @@ -191,7 +189,6 @@ kubectl get secret example-argocd-cluster -n argocd -ojsonpath='{.data.admin\.pa kubectl delete -n argocd -f examples/argocd-ingress.yaml ``` -[install_olm]:../install/olm.md [docs_argo]:https://argoproj.github.io/argo-cd/getting_started/#creating-apps-via-cli ### Host for Ingress in Argo CD Status diff --git a/argocd-operator/docs/usage/insights.md b/argocd-operator/docs/usage/insights.md index be09c1f6d85..db2ee93f184 100644 --- a/argocd-operator/docs/usage/insights.md +++ b/argocd-operator/docs/usage/insights.md @@ -8,8 +8,6 @@ Argo CD exports many metrics that can be used to monitor and provide insights in ## Cluster -This section builds on the example minishift cluster from the [OLM Install Guide][olm_guide]. - ## Prometheus The Prometheus Operator is available through [operatorhub.io](https://operatorhub.io/operator/prometheus) and is also present in the embedded OpenShift Operator Hub. @@ -34,8 +32,6 @@ Verify that an OperatorGroup is present in the namespace before creating the Sub kubectl get operatorgroups -n argocd ``` -The OperatorGroup created as part of the [OLM Istall Guide][olm_guide] will work. - ``` bash NAME AGE argocd-operator 2m47s @@ -150,5 +146,4 @@ oc -n argocd extract secret/example-argocd-cluster --to=- Refer to the [Ingress Guide][ingress_guide] for further steps on accessing these resources. -[olm_guide]:../install/olm.md [ingress_guide]:./ingress.md#access diff --git a/argocd-operator/docs/usage/routes.md b/argocd-operator/docs/usage/routes.md index 3763e27aeaf..85082578117 100644 --- a/argocd-operator/docs/usage/routes.md +++ b/argocd-operator/docs/usage/routes.md @@ -3,7 +3,7 @@ The Argo CD Operator offers support for managing OpenShift Routes to access the Argo CD resources. Once the operator is deployed and running, create a new ArgoCD custom resource. -The following [example](https://github.com/argoproj-labs/argocd-operator/blob/master/examples/argocd-route.yaml) shows the minimal required to create a new ArgoCD +The following [example](https://github.com/redhat-developer/gitops-operator/blob/master/examples/argocd-route.yaml) shows the minimal required to create a new ArgoCD environment with the default configuration. ``` bash diff --git a/argocd-operator/docs/usage/webhook-secrets.md b/argocd-operator/docs/usage/webhook-secrets.md index 4581674602f..4720114052c 100644 --- a/argocd-operator/docs/usage/webhook-secrets.md +++ b/argocd-operator/docs/usage/webhook-secrets.md @@ -29,7 +29,7 @@ This approach provides several benefits: When `spec.webhookSecrets` is configured, the operator automatically populates the appropriate keys in the `argocd-secret` Secret that Argo CD uses internally—using the **same `argocd-secret` data key names** documented in Argo CD’s [Git Webhook Configuration](https://argo-cd.readthedocs.io/en/stable/operator-manual/webhook/) (for example `webhook.github.secret`, `webhook.bitbucket.uuid`). A minimal GitHub-focused sample that can be adapted and applied lives in the operator repository: -[examples/argocd-webhook-secrets.yaml](https://github.com/argoproj-labs/argocd-operator/blob/master/examples/argocd-webhook-secrets.yaml). +[examples/argocd-webhook-secrets.yaml](https://github.com/redhat-developer/gitops-operator/blob/master/examples/argocd-webhook-secrets.yaml). ## Configuring webhook secrets @@ -53,7 +53,7 @@ For repository webhooks in the Git provider (payload URL `/api/webhook`, optiona | Gogs | `gogs` | `webhookSecretRef` | Webhook secret (→ `webhook.gogs.secret`) | | Azure DevOps | `azureDevOps` | `usernameSecretRef` and `passwordSecretRef` (both required) | Basic-auth username and password or PAT (→ `webhook.azuredevops.username` / `webhook.azuredevops.password`) | -The **`argocd-secret` keys** below match Argo CD’s [Git Webhook Configuration](https://argo-cd.readthedocs.io/en/stable/operator-manual/webhook/) section **Configure Argo CD With The WebHook Secret**. The operator uses the same string constants as upstream Argo CD (see [`common/keys.go`](https://github.com/argoproj-labs/argocd-operator/blob/master/common/keys.go) for the exact key name constants). +The **`argocd-secret` keys** below match Argo CD’s [Git Webhook Configuration](https://argo-cd.readthedocs.io/en/stable/operator-manual/webhook/) section **Configure Argo CD With The WebHook Secret**. The operator uses the same string constants as upstream Argo CD (see [`common/keys.go`](https://github.com/redhat-developer/gitops-operator/blob/master/argocd-operator/common/keys.go) for the exact key name constants). | Provider | Key in `argocd-secret` | |----------|-------------------------| diff --git a/argocd-operator/mkdocs.yml b/argocd-operator/mkdocs.yml index b540b3f265e..0d26b4d51f9 100644 --- a/argocd-operator/mkdocs.yml +++ b/argocd-operator/mkdocs.yml @@ -1,6 +1,6 @@ -site_name: Argo CD Operator -site_url: https://argocd-operator.readthedocs.io/en/latest/ -repo_url: https://github.com/argoproj-labs/argocd-operator +site_name: GitOps Operator +site_url: https://gitops-operator.readthedocs.io/en/latest/ +repo_url: https://github.com/redhat-developer/gitops-operator strict: true theme: name: material @@ -30,19 +30,14 @@ markdown_extensions: permalink: true nav: - Overview: index.md -- Release Process: release-process.md -- Security: SECURITY.md - Install: - Getting Started: install/start.md - OpenShift: install/openshift.md - - Operator Lifecycle Manager: install/olm.md - - Manual Installation: install/manual.md - Usage: - Basics: usage/basics.md - Config Management: usage/config_management_2.0.md - Custom Tooling: usage/customization.md - Deploy Resources to Different Namespaces: usage/deploy-to-different-namespaces.md - - Export: usage/export.md - ExtraConfig: usage/extra-config.md - High Availability: - Redis: usage/ha/redis.md @@ -67,16 +62,14 @@ nav: - ArgoCD: reference/argocd.md - ApplicationSet: - Policies: reference/applicationSet.md - - ArgoCDExport: reference/argocdexport.md - API Docs (v1beta1): reference/api-v1beta1.md - API Docs (v1alpha1): reference/api-v1alpha1.md - NotificationsConfiguration: reference/notificationsconfiguration.md - Contributing: - - Contributing: developer-guide/contributing.md - Development: - Setup: developer-guide/development.md - E2E Testing: developer-guide/e2e-test-guide.md - OLM Environment: developer-guide/olm-env.md - OpenAPI: developer-guide/openapi.md -- Releases ⧉: https://github.com/argoproj-labs/argocd-operator/releases +- Releases ⧉: https://github.com/redhat-developer/gitops-operator/releases - Upgrading: upgrading.md diff --git a/argocd-operator/examples/argocd-autoscale.yaml b/examples/argocd-autoscale.yaml similarity index 100% rename from argocd-operator/examples/argocd-autoscale.yaml rename to examples/argocd-autoscale.yaml diff --git a/argocd-operator/examples/argocd-basic.yaml b/examples/argocd-basic.yaml similarity index 100% rename from argocd-operator/examples/argocd-basic.yaml rename to examples/argocd-basic.yaml diff --git a/argocd-operator/examples/argocd-custom-cluster-domain.yaml b/examples/argocd-custom-cluster-domain.yaml similarity index 100% rename from argocd-operator/examples/argocd-custom-cluster-domain.yaml rename to examples/argocd-custom-cluster-domain.yaml diff --git a/argocd-operator/examples/argocd-image-updater.yaml b/examples/argocd-image-updater.yaml similarity index 100% rename from argocd-operator/examples/argocd-image-updater.yaml rename to examples/argocd-image-updater.yaml diff --git a/argocd-operator/examples/argocd-import.yaml b/examples/argocd-import.yaml similarity index 100% rename from argocd-operator/examples/argocd-import.yaml rename to examples/argocd-import.yaml diff --git a/argocd-operator/examples/argocd-ingress-openshift.yaml b/examples/argocd-ingress-openshift.yaml similarity index 100% rename from argocd-operator/examples/argocd-ingress-openshift.yaml rename to examples/argocd-ingress-openshift.yaml diff --git a/argocd-operator/examples/argocd-ingress.yaml b/examples/argocd-ingress.yaml similarity index 100% rename from argocd-operator/examples/argocd-ingress.yaml rename to examples/argocd-ingress.yaml diff --git a/argocd-operator/examples/argocd-insights.yaml b/examples/argocd-insights.yaml similarity index 100% rename from argocd-operator/examples/argocd-insights.yaml rename to examples/argocd-insights.yaml diff --git a/argocd-operator/examples/argocd-lb.yaml b/examples/argocd-lb.yaml similarity index 100% rename from argocd-operator/examples/argocd-lb.yaml rename to examples/argocd-lb.yaml diff --git a/argocd-operator/examples/argocd-nm.yaml b/examples/argocd-nm.yaml similarity index 100% rename from argocd-operator/examples/argocd-nm.yaml rename to examples/argocd-nm.yaml diff --git a/argocd-operator/examples/argocd-notifications.yaml b/examples/argocd-notifications.yaml similarity index 100% rename from argocd-operator/examples/argocd-notifications.yaml rename to examples/argocd-notifications.yaml diff --git a/argocd-operator/examples/argocd-oauth.yaml b/examples/argocd-oauth.yaml similarity index 100% rename from argocd-operator/examples/argocd-oauth.yaml rename to examples/argocd-oauth.yaml diff --git a/argocd-operator/examples/argocd-openshift-dex.yaml b/examples/argocd-openshift-dex.yaml similarity index 100% rename from argocd-operator/examples/argocd-openshift-dex.yaml rename to examples/argocd-openshift-dex.yaml diff --git a/argocd-operator/examples/argocd-resource-customizations.yaml b/examples/argocd-resource-customizations.yaml similarity index 100% rename from argocd-operator/examples/argocd-resource-customizations.yaml rename to examples/argocd-resource-customizations.yaml diff --git a/argocd-operator/examples/argocd-route.yaml b/examples/argocd-route.yaml similarity index 100% rename from argocd-operator/examples/argocd-route.yaml rename to examples/argocd-route.yaml diff --git a/argocd-operator/examples/argocd-webhook-secrets.yaml b/examples/argocd-webhook-secrets.yaml similarity index 100% rename from argocd-operator/examples/argocd-webhook-secrets.yaml rename to examples/argocd-webhook-secrets.yaml diff --git a/argocd-operator/examples/argocdexport-aws.yaml b/examples/argocdexport-aws.yaml similarity index 100% rename from argocd-operator/examples/argocdexport-aws.yaml rename to examples/argocdexport-aws.yaml diff --git a/argocd-operator/examples/argocdexport-azure.yaml b/examples/argocdexport-azure.yaml similarity index 100% rename from argocd-operator/examples/argocdexport-azure.yaml rename to examples/argocdexport-azure.yaml diff --git a/argocd-operator/examples/argocdexport-basic.yaml b/examples/argocdexport-basic.yaml similarity index 100% rename from argocd-operator/examples/argocdexport-basic.yaml rename to examples/argocdexport-basic.yaml diff --git a/argocd-operator/examples/argocdexport-gcp.yaml b/examples/argocdexport-gcp.yaml similarity index 100% rename from argocd-operator/examples/argocdexport-gcp.yaml rename to examples/argocdexport-gcp.yaml diff --git a/argocd-operator/examples/argocdexport-pvc.yaml b/examples/argocdexport-pvc.yaml similarity index 100% rename from argocd-operator/examples/argocdexport-pvc.yaml rename to examples/argocdexport-pvc.yaml diff --git a/argocd-operator/examples/namespaceManagement.yaml b/examples/namespaceManagement.yaml similarity index 100% rename from argocd-operator/examples/namespaceManagement.yaml rename to examples/namespaceManagement.yaml diff --git a/argocd-operator/examples/notificationsconfiguration.yaml b/examples/notificationsconfiguration.yaml similarity index 100% rename from argocd-operator/examples/notificationsconfiguration.yaml rename to examples/notificationsconfiguration.yaml diff --git a/argocd-operator/tests/ginkgo/README.md b/test/openshift/e2e/ginkgo/README.md similarity index 100% rename from argocd-operator/tests/ginkgo/README.md rename to test/openshift/e2e/ginkgo/README.md