fix-dead-urls-docs

CONTRIBUTING.md

@@ -38,7 +38,7 @@ The Open Cluster Management project has adopted the CNCF Code of Conduct. Refer
 
 ## Guidelines
 
-You can use a policy from the [`policy-collection/stable` folder](https://github.com/open-cluster-management-io/policy-collection/tree/main/stable), or create your own policy using the product policy framework. For more information, see _Policy overview_ in the [Open Cluster Management documentation](https://open-cluster-management.io/concepts/policy/). Use [NIST Special Publication 800-53](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final) to determine the correct NIST 800-53 Control Family for the policy.
+You can use a policy from the [`policy-collection/stable` folder](https://github.com/open-cluster-management-io/policy-collection/tree/main/stable), or create your own policy using the product policy framework. For more information, see _Policy overview_ in the [Open Cluster Management documentation](https://open-cluster-management.io/docs/concepts/policy/). Use [NIST Special Publication 800-53](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final) to determine the correct NIST 800-53 Control Family for the policy.
 
 Start with creating your own fork and clone the `policy-collection` repository for your local environment by running the following command: `git clone https://github.com/<your-username>/policy-collection.git`
 
@@ -49,36 +49,36 @@ For more information, see [GitHub documentation](https://docs.github.com/en/free
 Learn how to create a custom policy, validate that the custom policy is added, and add your policy to the `policy-collection` repository. Complete the following steps to create a custom policy:
 
 1. Create a new branch to develop a custom policy:
-   
+
    ```
    git checkout -b no-wildcard-roles
    ```
 
 2. Create a new YAML file in the community folder that corresponds to the Security Control Family. Use the [`policy-collection/stable` folder](https://github.com/open-cluster-management-io/policy-collection/tree/main/stable) for an example of the policy framework.
 
 3. Update the table in the [community README](https://github.com/open-cluster-management-io/policy-collection/blob/main/community/README.md) with the custom policy details by adding a new row to the table corresponding to the Security Control Family that we identified in the previous step. Provide the appropriate information in the format that is presented. For more about formatting the content, see GitHub’s Markdown guide. Your entry might resemble the following syntax:
-  
+
    ```
    [policy-name](./control-family/path/to/yaml) | <description> | <prerequisites>
    ```
-   
+
 ### Validate
 
-To validate the creation of your policy, login to the Open Cluster Management hub cluster to create a new policy using our custom YAML file. 
+To validate the creation of your policy, login to the Open Cluster Management hub cluster to create a new policy using our custom YAML file.
 
 1. Log in to the Open Cluster Management cluster so you can issue `kubectl` commands.
 
 2. Run the command: `kubectl create -f <yaml-filename> -n <namespace>` to apply the policy resources to the namespace you provide.
 
    **Note**: You can also validate your policy using GitOps instead of manually creating the policy.
 
-It is important to remember to set your policy to only inform users of policy violations by default and not enforce. You can test the enforcement of the policy if your policy supports it. For more information on which policies support enforcement, see [Policy controllers](https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.6/html/security/governance-and-risk#policy-controllers). 
+It is important to remember to set your policy to only inform users of policy violations by default and not enforce. You can test the enforcement of the policy if your policy supports it. For more information on which policies support enforcement, see [Policy controllers](https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.6/html/security/governance-and-risk#policy-controllers).
 
 Be sure that your contributed policy is set to `enforce` if the intent of your policy requires something to be created. For example, a policy that creates an operator would be expected to enforce creation of the operator. On the other hand, it is recommended for a configuration policy to be set to `inform` by default so that the policy does not change cluster resources automatically when it is applied.
 
 ### Contribute
 
-Create a pull request that can be reviewed by the product team. See the following instructions to populate a pull request: 
+Create a pull request that can be reviewed by the product team. See the following instructions to populate a pull request:
 
 1. Return to the `policy-collection` directory and add all changed files with the following command:
 
@@ -101,7 +101,7 @@ Create a pull request that can be reviewed by the product team. See the followin
    ```
 
 4. Copy and paste the URL to the pull request into your browser, which is provided in the output of the push command. Push changes from your fork back to the `open-cluster-management-io/policy-collection` repository.
-  
+
    Alternatively, view the [policy-collection compare page](https://github.com/open-cluster-management-io/policy-collection/compare), select **compare across forks**, and select your fork and branch from the drop-down list.
 
    **Tip:** Provide comments in the pull request to help describe any details about your policy that may be useful to reviewers.

README.md

@@ -105,17 +105,17 @@ For additional information about the Policy Generator:
 Distributing a `Policy` to a managed cluster requires four parts, all of which must be in the same
 namespace:
 
-- [Policy](https://open-cluster-management.io/concepts/policy/) is a grouping mechanism for Policy
+- [Policy](https://open-cluster-management.io/docs/concepts/policy/) is a grouping mechanism for Policy
   Templates and is the smallest deployable unit on the hub cluster. Embedded Policy Templates are
   distributed to applicable managed clusters and acted upon by the appropriate `policy controller`.
 
-- [PlacementBinding](https://open-cluster-management.io/concepts/policy/#placementbinding) binds a
+- [PlacementBinding](https://open-cluster-management.io/docs/concepts/policy/#placementbinding) binds a
   Placement to a `Policy` or `PolicySet`.
 
-- [Placement](https://open-cluster-management.io/concepts/placement/): Dynamically selects a set of
+- [Placement](https://open-cluster-management.io/docs/concepts/placement/): Dynamically selects a set of
   `ManagedClusters` in one or multiple `ManagedClusterSet`s.
 
-- [ManagedClusterSetBinding](https://open-cluster-management.io/concepts/managedclusterset/): Binds
+- [ManagedClusterSetBinding](https://open-cluster-management.io/docs/concepts/managedclusterset/): Binds
   a `ManagedClusterSet` to a namespace, making this group of managed clusters available for
   selection by `Placement`.
 
@@ -125,7 +125,7 @@ to the managed clusters and the `Policy` status will report on each cluster retu
 
 ### Using `Placement` with `Policies`
 
-See the [Placement documentation](https://open-cluster-management.io/concepts/placement/) for
+See the [Placement documentation](https://open-cluster-management.io/docs/concepts/placement/) for
 additional details on selecting managed clusters using `Placement`.
 
 - **NOTE:** `PlacementRule` is **deprecated**. See the
@@ -173,13 +173,13 @@ those managed clusters, bringing an additional layer of control to system admini
 following steps on migrating from `PlacementRule` to `Placement`:
 
 1. The desired managed clusters must be contained in a `ManagedClusterSet`. See the
-   [ManagedClusterSet documentation](https://open-cluster-management.io/concepts/managedclusterset/)
+   [ManagedClusterSet documentation](https://open-cluster-management.io/docs/concepts/managedclusterset/)
    to read more, including the default sets that are available that include all managed clusters
    that would replicate `PlacementRule` behavior.
 
 2. Create a `ManagedClusterSetBinding` to bind the `ManagedClusterSet` to the namespace where you
    are authoring policies. See the
-   [ManagedClusterSet documentation](https://open-cluster-management.io/concepts/managedclusterset/).
+   [ManagedClusterSet documentation](https://open-cluster-management.io/docs/concepts/managedclusterset/).
 
 3. Create the `Placement` manifest to replace the `PlacementRule`. To do this, take the selector
    `spec.clusterSelector` from the `PlacementRule` and put it into
@@ -199,7 +199,7 @@ following steps on migrating from `PlacementRule` to `Placement`:
            - {key: environment, operator: In, values: ["dev"]}
    ```
 
-See the [Placement documentation](https://open-cluster-management.io/concepts/placement/) for
+See the [Placement documentation](https://open-cluster-management.io/docs/concepts/placement/) for
 additional details on selecting managed clusters using `Placement`.
 
 4. Identify any `PlacementBinding` resources that reference a `PlacementRule`. Update the

policygenerator/policy-sets/community/kyverno/multitenancy/input/sharedresources/add-managedclustersetbinding-shared-sre-group.yaml

@@ -9,7 +9,7 @@ metadata:
     policies.kyverno.io/subject: ClusterRoleBinding
     policies.kyverno.io/description: >-
       Note that binding a cluster set to a namespace means that granting access from that namespace to its member clusters. And the bind process requires “managedclustersets/bind” access in the hub cluster which is clarified below. This means you can deploy an ApplicationSet to that namespace and it will be deployed on all Clusters which match the label in the Placement
-      read more at https://open-cluster-management.io/concepts/managedclusterset/#bind-the-clusterset-to-a-workspace-namespace 
+      read more at https://open-cluster-management.io/docs/concepts/managedclusterset/#bind-the-clusterset-to-a-workspace-namespace
 spec:
   background: false
   rules:
@@ -23,7 +23,7 @@ spec:
         - kind: Group
           name: "blue-sre-group"
         - kind: Group
-          name: "red-sre-group"          
+          name: "red-sre-group"
     preconditions:
       any:
       - key: "{{request.operation}}"
@@ -33,7 +33,7 @@ spec:
         - UPDATE
       - key: "{{request.object.metadata.name}}"
         operator: AnyNotIn
-        value: shared*              
+        value: shared*
     generate:
       apiVersion: cluster.open-cluster-management.io/v1beta2
       kind: ManagedClusterSetBinding
@@ -53,17 +53,17 @@ spec:
         - kind: Group
           name: "red-sre-group"
         - kind: Group
-          name: "blue-sre-group"          
+          name: "blue-sre-group"
     preconditions:
       any:
       - key: "{{request.operation}}"
         operator: In
         value:
         - CREATE
-        - UPDATE  
+        - UPDATE
       - key: "{{request.object.metadata.name}}"
         operator: AnyNotIn
-        value: shared*           
+        value: shared*
     generate:
       apiVersion: cluster.open-cluster-management.io/v1beta2
       kind: ManagedClusterSetBinding
@@ -83,7 +83,7 @@ spec:
         - kind: Group
           name: "red-sre-group"
         - kind: Group
-          name: "blue-sre-group"          
+          name: "blue-sre-group"
     preconditions:
       any:
       - key: "{{request.operation}}"
@@ -101,8 +101,4 @@ spec:
         - requiredClusterSelector:
             labelSelector:
               matchLabels:
-                env: dev   
-
-
-
-
+                env: dev