Rename `HelmApp` to `HelmOp in the repo

Signed-off-by: Furkat Gofurov <furkat.gofurov@suse.com>

README.md

@@ -9,7 +9,7 @@ Cluster API Add-on Provider for Fleet (CAAPF) is a Cluster API (CAPI) provider t
 It provides the following functionality:
 
 - Addon provider automatically installs `Fleet` in your management cluster.
-- The provider will register a newly provisioned CAPI cluster with `Fleet` so that applications can be automatically deployed to the created cluster via GitOps, `Bundle` or `HelmApp`.
+- The provider will register a newly provisioned CAPI cluster with `Fleet` so that applications can be automatically deployed to the created cluster via GitOps, `Bundle` or `HelmOp`.
 - The provider will automatically create a [Fleet Cluster Group](https://fleet.rancher.io/cluster-group) for every [CAPI ClusterClass](https://cluster-api.sigs.k8s.io/tasks/experimental-features/cluster-class/). This enables you to deploy the same applications to all clusters created from the same ClusterClass.
 - `CAPI` `Cluster`, `ControlPlane` resources are automatically added to the `Fleet` `Cluster` resource templates, allowing to perform per-cluster configuration templating for `Helm` based installations.
 

docs/src/00_intro.md

@@ -5,7 +5,7 @@ Cluster API Add-on Provider for Fleet (CAAPF) is a Cluster API (CAPI) provider t
 It provides the following functionality:
 
 - Addon provider automatically installs `Fleet` in your management cluster.
-- The provider will register a newly provisioned CAPI cluster with `Fleet` so that applications can be automatically deployed to the created cluster via GitOps, `Bundle` or `HelmApp`.
+- The provider will register a newly provisioned CAPI cluster with `Fleet` so that applications can be automatically deployed to the created cluster via GitOps, `Bundle` or `HelmOp`.
 - The provider will automatically create a [Fleet Cluster Group](https://fleet.rancher.io/cluster-group) for every [CAPI ClusterClass](https://cluster-api.sigs.k8s.io/tasks/experimental-features/cluster-class/). This enables you to deploy the same applications to all clusters created from the same ClusterClass.
 - `CAPI` `Cluster`, `ControlPlane` resources are automatically added to the `Fleet` `Cluster` resource templates, allowing to perform per-cluster configuration templating for `Helm` based installations.
 

docs/src/01_motivation.md

@@ -8,7 +8,7 @@ One of the projects involved in deploying `Helm` charts on CAPI-provisioned clus
 
 [CAAPH]: https://github.com/kubernetes-sigs/cluster-api-addon-provider-helm
 
-Fleet also supports deploying Helm charts via the (experimental) `HelmApp` resource, which offers similar capabilities to `HelmChartProxy`. However, Fleet primarily focuses on providing `GitOps` capabilities for managing `CAPI` clusters and application states within these clusters.
+Fleet also supports deploying Helm charts via the (experimental) `HelmOp` resource, which offers similar capabilities to `HelmChartProxy`. However, Fleet primarily focuses on providing `GitOps` capabilities for managing `CAPI` clusters and application states within these clusters.
 
 Out of the box, `Fleet` allows users to deploy and maintain the state of arbitrary templates on child clusters using the `Fleet` [`Bundle`][] resource. This approach addresses the need for alternatives to [`ClusterResourceSet`][] while offering full application lifecycle management.
 

docs/src/02_getting_started/02_configuration.md

@@ -85,7 +85,7 @@ spec:
 
 Fleet includes experimental features that can be enabled or disabled using feature gates in the `FleetAddonConfig` resource. These flags are configured under .spec.config.featureGates.
 
-To enable experimental features such as OCI storage support and `HelmApp` support, update the FleetAddonConfig as follows:
+To enable experimental features such as OCI storage support and `HelmOp` support, update the FleetAddonConfig as follows:
 
 ```yaml
 apiVersion: addons.cluster.x-k8s.io/v1alpha1

docs/src/03_tutorials/03_installing_calico.md

@@ -1,18 +1,18 @@
-# Installing Calico CNI using HelmApp
+# Installing Calico CNI using HelmOp
 
 <div class="warning">
 
 Note: For this setup to work, you need to install Fleet and Fleet CRDs charts via
 `FleetAddonConfig` resource. Both need to have version >= v0.12.0,
-which provides support for `HelmApp` resource.
+which provides support for `HelmOp` resource.
 
 </div>
 
-In this tutorial we will deploy `Calico` CNI using `HelmApp` resource and `Fleet` cluster substitution mechanism.
+In this tutorial we will deploy `Calico` CNI using `HelmOp` resource and `Fleet` cluster substitution mechanism.
 
 ## Deploying Calico CNI
 
-Here's an example of how a `HelmApp` resource can be used in combination with templateValues to deploy application consistently on any matching cluster.
+Here's an example of how a `HelmOp` resource can be used in combination with templateValues to deploy application consistently on any matching cluster.
 
 In this scenario we are matching cluster directly by name, using `clusterName` reference, but a `clusterGroup` or a label based selection can be used instead or together with `clusterName`:
 ```yaml
@@ -20,13 +20,13 @@ In this scenario we are matching cluster directly by name, using `clusterName` r
   - clusterName: docker-demo
 ```
 
-We are deploying `HelmApp` resource in the `default` namespace. The namespace should be the same for the CAPI Cluster for fleet to locate it.
+We are deploying `HelmOp` resource in the `default` namespace. The namespace should be the same for the CAPI Cluster for fleet to locate it.
 
 ```yaml
 {{#include ../../../testdata/helm.yaml}}
 ```
 
-`HelmApp` supports fleet [templating][] options, otherwise available exclusively to the `fleet.yaml` configuration, stored in the [git repository contents][], and applied via the `GitRepo` resource.
+`HelmOp` supports fleet [templating][] options, otherwise available exclusively to the `fleet.yaml` configuration, stored in the [git repository contents][], and applied via the `GitRepo` resource.
 
 [templating]: https://fleet.rancher.io/ref-fleet-yaml#templating
 [git repository contents]: https://fleet.rancher.io/gitrepo-content
@@ -37,12 +37,12 @@ After appying the resource we will observe the app rollout:
 
 ```bash
 > kubectl apply -f testdata/helm.yaml
-helmapp.fleet.cattle.io/calico created
-> kubectl get helmapp
+helmop.fleet.cattle.io/calico created
+> kubectl get helmop
 NAME     REPO                                   CHART             VERSION   BUNDLEDEPLOYMENTS-READY   STATUS
 calico   https://docs.tigera.io/calico/charts   tigera-operator   v3.29.2   0/1                       NotReady(1) [Bundle calico]; apiserver.operator.tigera.io default [progressing]
 # After some time
-> kubectl get helmapp
+> kubectl get helmop
 NAME     REPO                                   CHART             VERSION   BUNDLEDEPLOYMENTS-READY   STATUS
 calico   https://docs.tigera.io/calico/charts   tigera-operator   v3.29.2   1/1
 > kubectl get pods -n calico-system --context capi-quickstart

docs/src/03_tutorials/04_installing_calico_via_gitrepo.md

@@ -47,7 +47,7 @@ We will first review the content of our `fleet.yaml` file:
 {{#include ../../../fleet/applications/calico/fleet.yaml}}
 ```
 
-In this scenario we are using `helm` definition which is consistent with the `HelmApp` spec from the [previous][] guide, and defines same templating rules.
+In this scenario we are using `helm` definition which is consistent with the `HelmOp` spec from the [previous][] guide, and defines same templating rules.
 
 We also need to [resolve conflicts][], which happen due to in-place modification of some resources by the `calico` controllers. For that, the `diff` section is used, where we remove blocking fields from comparison.
 

docs/src/04_reference/01_import-strategy.md

@@ -5,7 +5,7 @@ CAAPF follows a simple import strategy for CAPI clusters:
 1. Each CAPI cluster has a corresponding Fleet `Cluster` object.
 2. Each CAPI Cluster Class has a corresponding Fleet `ClusterGroup` object.
 3. When a CAPI `Cluster` references a `ClusterClass` in a different namespace, a `ClusterGroup` is created in the `Cluster` namespace. This `ClusterGroup` targets all clusters in this namespace that reference the same `ClusterClass`. See the [configuration](03_fleet-addon-config#applyclassgroup) section for details.
-4. If at least one CAPI `Cluster` references a `ClusterClass` in a different namespace, a [`BundleNamespaceMapping`][mapping] is created in the `ClusterClass` namespace. This allows Fleet `Cluster` resources to use application sources such as `Bundles`, `HelmApps`, or `GitRepos` from the `ClusterClass` namespace as if they were deployed in the `Cluster` namespace. See the [configuration](#cluster-clustergroupbundlenamespacemapping-configuration) section for details.
+4. If at least one CAPI `Cluster` references a `ClusterClass` in a different namespace, a [`BundleNamespaceMapping`][mapping] is created in the `ClusterClass` namespace. This allows Fleet `Cluster` resources to use application sources such as `Bundles`, `HelmOps`, or `GitRepos` from the `ClusterClass` namespace as if they were deployed in the `Cluster` namespace. See the [configuration](#cluster-clustergroupbundlenamespacemapping-configuration) section for details.
 
 [mapping]: https://fleet.rancher.io/namespaces#cross-namespace-deployments
 

docs/src/04_reference/02_templating-strategy.md

@@ -14,6 +14,6 @@ The **Addon Provider Fleet** ensures that the state of a CAPI cluster and resour
 - Maintain a consistent application state across different clusters.
 - Use the same template for multiple matching clusters to simplify deployment and management.
 
-## Example - templating withing HelmApp
+## Example - templating withing HelmOp
 
 -> [Installing Calico](../03_tutorials/03_installing_calico.md#deploying-calico-cni)

docs/src/04_reference/03_fleet-addon-config.md

@@ -211,7 +211,7 @@ It is a required field and provides a config for fleet addon functionality.
         -   `clusterclass-name.fleet.addons.cluster.x-k8s.io: <class-name>`
         -   `clusterclass-namespace.fleet.addons.cluster.x-k8s.io: <class-ns>`
 
-        Additionally, this configuration enables the creation of a `BundleNamespaceMapping`. This mapping selects all available bundles and establishes a link between the namespace of the `Cluster` and the namespace of the referenced `ClusterClass`. This allows the Fleet `Cluster` to be evaluated as a target for application sources such as `Bundles`, `HelmApps`, or `GitRepos` from the **`ClusterClass`** namespace.
+        Additionally, this configuration enables the creation of a `BundleNamespaceMapping`. This mapping selects all available bundles and establishes a link between the namespace of the `Cluster` and the namespace of the referenced `ClusterClass`. This allows the Fleet `Cluster` to be evaluated as a target for application sources such as `Bundles`, `HelmOps`, or `GitRepos` from the **`ClusterClass`** namespace.
 
         When all CAPI `Cluster` resources referencing the same `ClusterClass` are removed, both the `ClusterGroup` and `BundleNamespaceMapping` are cleaned up.
 

testdata/config.yaml

@@ -21,5 +21,5 @@ spec:
       matchLabels:
         import: ""
   install:
-    followLatest: true # We will install alpha for helmapp support
+    followLatest: true # We will install alpha for helmop support
 

testdata/helm.yaml

@@ -1,5 +1,5 @@
 apiVersion: fleet.cattle.io/v1alpha1
-kind: HelmApp
+kind: HelmOp
 metadata:
   name: calico
 spec: