// Module included in the following assemblies:
//
// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc

:_mod-docs-content-type: REFERENCE
[id="telco-ran-gitops-operator-and-ztp-plugins_{context}"]
= GitOps Operator and {ztp}

[role="_abstract"]
GitOps Operator and {ztp} provide a GitOps-based infrastructure for managing cluster deployment and configuration.

New in this release::
* No reference design updates in this release

Description::
+
--
GitOps Operator and {ztp} provide a GitOps-based infrastructure for managing cluster deployment and configuration.
Cluster definitions and configurations are maintained as a declarative state in Git.
You can apply `ClusterInstance` CRs to the hub cluster where the `SiteConfig` Operator renders them as installation CRs.
In earlier releases, a {ztp} plugin supported the generation of installation CRs from `SiteConfig` CRs.
This plugin is now removed.
A separate {ztp} plugin is available to enable automatic wrapping of configuration CRs into policies based on the `PolicyGenerator` or `PolicyGenTemplate` CR.

You can deploy and manage multiple versions of {product-title} on managed clusters using the baseline reference configuration CRs.
You can use custom CRs alongside the baseline CRs.
To maintain multiple per-version policies simultaneously, use Git to manage the versions of the source and policy CRs by using `PolicyGenerator` or `PolicyGenTemplate` CRs.
{rh-rhacm} `PolicyGenerator` is the recommended generator plugin starting from {product-title} 4.19 release.
--

Limits and requirements::
// Scale results ACM-17868
* 1000 `ClusterInstance` CRs per ArgoCD application on a hub cluster conforming to the Hub RDS.
Multiple applications can be used to achieve the maximum number of clusters supported by a single hub cluster
* Content in the `source-crs/` directory in Git overrides content provided in the ZTP plugin container, as Git takes precedence in the search path.
* The `source-crs/` directory must be located in the same directory as the `kustomization.yaml` file, which includes `PolicyGenerator` CRs as a generator.
Alternative locations for the `source-crs/` directory are not supported in this context.

Engineering considerations::
* For multi-node cluster upgrades, you can pause `MachineConfigPool` (`MCP`) CRs during maintenance windows by setting the `paused` field to `true`.
You can increase the number of simultaneously updated nodes per `MCP` CR by configuring the `maxUnavailable` setting in the `MCP` CR.
The `MaxUnavailable` field defines the percentage of nodes in the pool that can be simultaneously unavailable during a `MachineConfig` update.
Set `maxUnavailable` to the maximum tolerable value.
This reduces the number of reboots in a cluster during upgrades which results in shorter upgrade times.
When you finally unpause the `MCP` CR, all the changed configurations are applied with a single reboot.
* During cluster installation, you can pause custom MCP CRs by setting the paused field to true and setting `maxUnavailable` to 100% to improve installation times.
* Keep reference CRs and custom CRs under different directories.
Doing this allows you to patch and update the reference CRs by simple replacement of all directory contents without touching the custom CRs.
When managing multiple versions, the following best practices are recommended:
** Keep all source CRs and policy creation CRs in Git repositories to ensure consistent generation of policies for each {product-title} version based solely on the contents in Git.
** Keep reference source CRs in a separate directory from custom CRs.
This facilitates easy update of reference CRs as required.
* To avoid confusion or unintentional overwrites when updating content, it is highly recommended to use unique and distinguishable names for custom CRs in the `source-crs/` directory and extra manifests in Git.
* Extra installation manifests are referenced in the `ClusterInstance` CR through a `ConfigMap` CR.
The `ConfigMap` CR should be stored alongside the `ClusterInstance` CR in Git, serving as the single source of truth for the cluster.
If needed, you can use a `ConfigMap` generator to create the `ConfigMap` CR.
