<commit_before>// Module included in the following assemblies:
//
// *scalability_and_performance/ztp-zero-touch-provisioning.adoc

[id="ztp-validating-the-generation-of-policy-crs_{context}"]
= Validating the generation of policy CRs

ArgoCD generates the policy custom resources (CRs) in the same namespace as the `PolicyGenTemplate` from which they were created. The same troubleshooting flow applies to all policy CRs generated from `PolicyGenTemplates` regardless of whether they are common, group, or site based.

To check the status of the policy CRs, enter the following commands:

[source,terminal]
----
$ export NS=<namespace>
----

[source,terminal]
----
$ oc get policy -n $NS
----

The returned output displays the expected set of policy wrapped CRs. If no object is returned, use the following procedure to troubleshoot the ArgoCD pipeline flow from `SiteConfig` to the policy CRs.

.Procedure

. Check the synchronization of the `PolicyGenTemplate` to the hub cluster:
+
[source,terminal]
----
$ oc get policygentemplate -A
----
or
+
[source,terminal]
----
$ oc get policygentemplate -n $NS
----
+
If the `PolicyGenTemplate` is not synchronized, one of the following situations has occurred:
+
* The clusters application failed to synchronize the CR from the Git repository to the hub. Use the following command to verify this:
+
[source,terminal]
----
$ oc describe -n openshift-gitops application clusters
----
+
Check for `Status: Synced` and that the `Revision:` is the SHA of the commit you pushed to the subscribed repository.
+
* The pre-sync hook failed, possibly due to a failure to pull the container image. Check the ArgoCD dashboard for the status of the pre-sync job in the *clusters* application.

. Ensure the policies were copied to the cluster namespace. When ACM recognizes that policies apply to a `ManagedCluster`, ACM applies the policy CR objects to the cluster namespace:
+
[source,terminal]
----
$ oc get policy -n <clusterName>
----
ACM copies all applicable common, group, and site policies here. The policy names are `<policyNamespace>` and `<policyName>`.

. Check the placement rule for any policies not copied to the cluster namespace. The `matchSelector` in the `PlacementRule` for those policies should match the labels on the `ManagedCluster`:
+
[source,terminal]
----
$ oc get placementrule -n $NS
----

. Make a note of the `PlacementRule` name for the missing common, group, or site policy:
+
[source,terminal]
----
 oc get placementrule -n $NS <placmentRuleName> -o yaml
----
+
* The `status decisions` value should include your cluster name.
* The `key value` of the `matchSelector` in the spec should match the labels on your managed cluster. Check the labels on `ManagedCluster`:
+
[source,terminal]
----
 oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq
----
+
.Example
[source,yaml]
----
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: group-test1-policies-placementrules
  namespace: group-test1-policies
spec:
  clusterSelector:
    matchExpressions:
    - key: group-test1
      operator: In
      values:
      - ""
status:
  decisions:
  - clusterName: <myClusterName>
    clusterNamespace: <myClusterName>
----

. Ensure all policies are compliant:
+
[source,terminal]
----
 oc get policy -n $CLUSTER
----
+

If the Namespace, OperatorGroup, and Subscription policies are compliant but the operator configuration policies are not it is likely that the operators did not install.<commit_msg>Capitalising Operator references<commit_after>// Module included in the following assemblies:
//
// *scalability_and_performance/ztp-zero-touch-provisioning.adoc

[id="ztp-validating-the-generation-of-policy-crs_{context}"]
= Validating the generation of policy CRs

ArgoCD generates the policy custom resources (CRs) in the same namespace as the `PolicyGenTemplate` from which they were created. The same troubleshooting flow applies to all policy CRs generated from `PolicyGenTemplates` regardless of whether they are common, group, or site based.

To check the status of the policy CRs, enter the following commands:

[source,terminal]
----
$ export NS=<namespace>
----

[source,terminal]
----
$ oc get policy -n $NS
----

The returned output displays the expected set of policy wrapped CRs. If no object is returned, use the following procedure to troubleshoot the ArgoCD pipeline flow from `SiteConfig` to the policy CRs.

.Procedure

. Check the synchronization of the `PolicyGenTemplate` to the hub cluster:
+
[source,terminal]
----
$ oc get policygentemplate -A
----
or
+
[source,terminal]
----
$ oc get policygentemplate -n $NS
----
+
If the `PolicyGenTemplate` is not synchronized, one of the following situations has occurred:
+
* The clusters application failed to synchronize the CR from the Git repository to the hub. Use the following command to verify this:
+
[source,terminal]
----
$ oc describe -n openshift-gitops application clusters
----
+
Check for `Status: Synced` and that the `Revision:` is the SHA of the commit you pushed to the subscribed repository.
+
* The pre-sync hook failed, possibly due to a failure to pull the container image. Check the ArgoCD dashboard for the status of the pre-sync job in the *clusters* application.

. Ensure the policies were copied to the cluster namespace. When ACM recognizes that policies apply to a `ManagedCluster`, ACM applies the policy CR objects to the cluster namespace:
+
[source,terminal]
----
$ oc get policy -n <clusterName>
----
ACM copies all applicable common, group, and site policies here. The policy names are `<policyNamespace>` and `<policyName>`.

. Check the placement rule for any policies not copied to the cluster namespace. The `matchSelector` in the `PlacementRule` for those policies should match the labels on the `ManagedCluster`:
+
[source,terminal]
----
$ oc get placementrule -n $NS
----

. Make a note of the `PlacementRule` name for the missing common, group, or site policy:
+
[source,terminal]
----
 oc get placementrule -n $NS <placmentRuleName> -o yaml
----
+
* The `status decisions` value should include your cluster name.
* The `key value` of the `matchSelector` in the spec should match the labels on your managed cluster. Check the labels on `ManagedCluster`:
+
[source,terminal]
----
 oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq
----
+
.Example
[source,yaml]
----
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: group-test1-policies-placementrules
  namespace: group-test1-policies
spec:
  clusterSelector:
    matchExpressions:
    - key: group-test1
      operator: In
      values:
      - ""
status:
  decisions:
  - clusterName: <myClusterName>
    clusterNamespace: <myClusterName>
----

. Ensure all policies are compliant:
+
[source,terminal]
----
 oc get policy -n $CLUSTER
----
+

If the Namespace, OperatorGroup, and Subscription policies are compliant but the Operator configuration policies are not it is likely that the Operators did not install.
{'fraction_non_alphanumeric': 0.09546810626509447, 'fraction_numerical': 0.001136525074584458, 'mean_word_length': 3.9893692416725726, 'pattern_counts': {'":': 0, '<': 17, '<?xml version=': 0, '>': 17, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4820357', 'n_tokens_mistral': 1969, 'n_tokens_neox': 1922, 'n_words': 865}