docs: ApplicationSet Cluster Decision Resource Generator - update OCM references from deprecated PlacementRule to PlacementDecision (#28307)

Signed-off-by: Mike Ng <[email protected]>

applicationset/examples/clusterDecisionResource/README.md

@@ -37,17 +37,17 @@ data:
 
 # Applying the example
 1. Connect to a cluster with the ApplicationSet controller running
-2. Edit the Role for the ApplicationSet service account, and grant it permission to `list` the `placementdecisions` resources, from apiGroups `cluster.open-cluster-management.io/v1alpha1`
+2. Edit the Role for the ApplicationSet service account, and grant it permission to `list` the `placementdecisions` resources, from apiGroups `cluster.open-cluster-management.io`
 ```yaml
 - apiGroups:
-  - "cluster.open-cluster-management.io/v1alpha1"
+  - "cluster.open-cluster-management.io"
   resources:
   - placementdecisions
   verbs:
   - list
 ```
-3. Apply the following controller and associated ManagedCluster CRD's:
-https://github.com/open-cluster-management/placement
+3. Deploy the open-cluster-management Placement controller:
+https://open-cluster-management.io/docs/concepts/content-placement/placement/
 4. Now apply the PlacementDecision and an ApplicationSet:
 ```bash
 kubectl apply -f ./placementdecision.yaml

applicationset/examples/clusterDecisionResource/configMap.yaml

@@ -1,11 +1,12 @@
-# To generate a Status.Decisions from this CRD, requires https://github.com/open-cluster-management/multicloud-operators-placementrule be deployed
+# To generate a Status.Decisions from this CRD, requires the open-cluster-management.io Placement controller be deployed.
+# See: https://open-cluster-management.io/docs/concepts/content-placement/placement/
 ---
 apiVersion: v1
 kind: ConfigMap
 metadata:
   name: ocm-placement
 data:
-  apiVersion: apps.open-cluster-management.io/v1
-  kind: placementrules
+  apiVersion: cluster.open-cluster-management.io/v1beta1
+  kind: placementdecisions
   statusListKey: decisions
   matchKey: clusterName

applicationset/examples/clusterDecisionResource/placementdecision.yaml

@@ -1,18 +1,15 @@
 ---
-apiVersion: apps.open-cluster-management.io/v1
-kind: PlacementRule
+# PlacementDecision is created by the Placement controller to hold scheduling results.
+# A Placement resource defines the scheduling policy; the controller then populates
+# one or more PlacementDecision resources with the selected clusters.
+# See: https://open-cluster-management.io/docs/concepts/content-placement/placement/#placementdecisions
+apiVersion: cluster.open-cluster-management.io/v1beta1
+kind: PlacementDecision
 metadata:
   name: test-placement
-spec:
-  clusterReplicas: 1   # Availability choice, maximum number of clusters to provision at once
-  clusterSelector:
-    matchLabels:
-      'usage': 'development'
-  clusterConditions:
-    - type: ManagedClusterConditionAvailable
-      status: "True"
-# Below is sample output the generator can consume.
+  labels:
+    cluster.open-cluster-management.io/placement: test-placement
 status:
   decisions:
   - clusterName: cluster-01
-  - clusterName: cluster-02
+  - clusterName: cluster-02

docs/operator-manual/applicationset/Generators-Cluster-Decision-Resource.md

@@ -72,10 +72,10 @@ data:
 
 (*The [full example](https://github.com/argoproj/argo-cd/tree/master/applicationset/examples/clusterDecisionResource)*)
 
-This example leverages the cluster management capabilities of the [open-cluster-management.io community](https://open-cluster-management.io/). By creating a `ConfigMap` with the GVK for the `open-cluster-management.io` Placement rule, your ApplicationSet can provision to different clusters in a number of novel ways. One example is to have the ApplicationSet maintain only two Argo CD Applications across 3 or more clusters. Then as maintenance or outages occur, the ApplicationSet will always maintain two Applications, moving the application to available clusters under the Placement rule's direction. 
+This example leverages the cluster management capabilities of the [open-cluster-management.io community](https://open-cluster-management.io/). By creating a `ConfigMap` with the GVK for the `open-cluster-management.io` [`PlacementDecision`](https://open-cluster-management.io/docs/concepts/content-placement/placement/#placementdecisions), your ApplicationSet can provision to different clusters in a number of novel ways. One example is to have the ApplicationSet maintain only two Argo CD Applications across 3 or more clusters. Then as maintenance or outages occur, the ApplicationSet will always maintain two Applications, moving the application to available clusters under the [`Placement`](https://open-cluster-management.io/docs/concepts/content-placement/placement/) controller's direction.
 
 ## How it works
-The ApplicationSet needs to be created in the Argo CD namespace, placing the `ConfigMap` in the same namespace allows the ClusterDecisionResource generator to read it. The `ConfigMap` stores the GVK information as well as the status key definitions.  In the open-cluster-management example, the ApplicationSet generator will read the kind `placementrules` with an apiVersion of `apps.open-cluster-management.io/v1`. It will attempt to extract the **list** of clusters from the key `decisions`. It then validates the actual cluster name as defined in Argo CD against the **value** from the key `clusterName` in each of the elements in the list.
+The ApplicationSet needs to be created in the Argo CD namespace, placing the `ConfigMap` in the same namespace allows the ClusterDecisionResource generator to read it. The `ConfigMap` stores the GVK information as well as the status key definitions.  In the open-cluster-management example, the ApplicationSet generator will read the kind `placementdecisions` with an apiVersion of `cluster.open-cluster-management.io/v1beta1`. It will attempt to extract the **list** of clusters from the key `decisions`. It then validates the actual cluster name as defined in Argo CD against the **value** from the key `clusterName` in each of the elements in the list.
 
 The ClusterDecisionResource generator passes the 'name', 'server' and any other key/value in the duck-type resource's status list as parameters into the ApplicationSet template. In this example, the decision array contained an additional key `clusterName`, which is now available to the ApplicationSet template.