Fixed warnings for snippet files

Author: jasonnovichRunAI

docs/Researcher/best-practices/convert-to-unattended.md

@@ -11,7 +11,7 @@ Unattended workloads are a good fit for long-duration runs, or sets of smaller h
 
 ### Docker Image
 
-A docker container is based on a docker image. Some Researchers use generic images such as ones provided by Nvidia, for example: [NVIDIA NGC TensorFlow](https://ngc.nvidia.com/catalog/containers/nvidia:tensorflow){target=_blank}. 
+A docker container is based on a docker image. Some Researchers use generic images such as ones provided by Nvidia, for example: [NVIDIA NGC TensorFlow](https://ngc.nvidia.com/catalog/containers/nvidia:tensorflow){target=_blank}.
 Others, use generic images as the __base__ image to a more customized image using [Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/){target=_blank}.
 
 Realizing that Researchers are not always proficient with building docker files, as a best practice, you will want to:
@@ -26,17 +26,17 @@ You will want to minimize the cycle of code change-and-run. There are a couple o
 
 1. Code resides on the network file storage. This way you can change the code and immediately run the Job. The Job picks up the new files from the network.
 2. Use the `runai submit` flag `--git-sync`. The flag allows the Researcher to provide details of a Git repository. The repository will be automatically cloned into a specified directory when the container starts.
-3. The code can be embedded within the image. In this case, you will want to create an automatic CI/CD process, which packages the code into a modified image. 
+3. The code can be embedded within the image. In this case, you will want to create an automatic CI/CD process, which packages the code into a modified image.
 
-The document below assumes option #1. 
+The document below assumes option #1.
 
 ### Create a Startup Script
 
 Gather the commands you ran inside the interactive Job into a single script. The script will be provided with the command-line at the start of the unattended execution (see the section _running the job_ below). This script should be kept next to your code, on a shared network drive (e.g. _/nfs/john_).
 
 An example of a common startup script __start.sh__:
 
-``` 
+```
 pip install -r requirements.txt
 ...
 python training.py
@@ -97,7 +97,7 @@ Please refer to [Command-Line Interface, runai submit](../cli-reference/runai-su
 
 ### Use CLI Policies
 
-Different run configurations may vary significantly and can be tedious to be written each time on the command-line. To make life easier, our CLI offers a way to set administrator policies for these configurations and use pre-configured configuration when submitting a Workload. Please refer to [Configure Command-Line Interface Policies](../../admin/workloads/policies.md). 
+Different run configurations may vary significantly and can be tedious to be written each time on the command-line. To make life easier, our CLI offers a way to set administrator policies for these configurations and use pre-configured configuration when submitting a Workload. Please refer to [Configure Command-Line Interface Policies](../../admin/workloads/policies/policies.md).
 
 ## Attached Files
 

docs/Researcher/cli-reference/runai-submit.md

@@ -453,4 +453,4 @@ Note that the submit call may use a *policy* to provide defaults to any of the a
 ## See Also
 
 * See any of the Quickstart documents [here:](../Walkthroughs/quickstart-overview.md).
-* See [policy configuration](../../admin/workloads/policies.md) for a description on how policies work.
+* See [policy configuration](../../admin/workloads/policies/policies.md) for a description on how policies work.

docs/Researcher/user-interface/workspaces/create/workspace-v2.md

@@ -24,7 +24,7 @@ Use the *Jobs form* below if you have not enabled the *Workloads* feature.
           A template contains a set of predefined building blocks as well as additional configurations which allow the user to immediately create a templated-based workspace.
 
       4. Enter a name for your workspace and press *Continue*.
-      5. Select an environment from the tiles. If your environment is not listed, use the *Search environments* box to find it or press [*New environment*](workspaces/create/create-env.md) to create a new environment. Press  to create an environment if needed. In the *Set the connection for your tool(s)*, enter the URL of the tool if a custom URL has been enabled in the selected environment. Use the *Private* toggle to lock access to the tool to only the creator of the environment.
+      5. Select an environment from the tiles. If your environment is not listed, use the *Search environments* box to find it or press [*New environment*](../create/create-env.md) to create a new environment. Press  to create an environment if needed. In the *Set the connection for your tool(s)*, enter the URL of the tool if a custom URL has been enabled in the selected environment. Use the *Private* toggle to lock access to the tool to only the creator of the environment.
 
          In the *Runtime Settings*:
 

docs/admin/admin-ui-setup/templates.md

@@ -16,15 +16,15 @@ To create a template:
 1. In the left menu, press *Templates*, then press *New Template*.
 2. In the *Scope* pane, select a *Scope*.
 3. In the *Template Name* pane, enter a name for the template.
-3. Select an environment from the tiles. If your environment is not listed, use the *Search environments* box to find it or press [*New environment*](workspaces/create/create-env.md) to create a new environment. Press  to create an environment if needed. In the *Set the connection for your tool(s)*, enter the URL of the tool if a custom URL has been enabled in the selected environment. Use the *Private* toggle to lock access to the tool to only the creator of the environment.
+4. Select an environment from the tiles. If your environment is not listed, use the *Search environments* box to find it or press [*New environment*](../../Researcher/user-interface/workspaces/create/create-env.md) to create a new environment. Press  to create an environment if needed. In the *Set the connection for your tool(s)*, enter the URL of the tool if a custom URL has been enabled in the selected environment. Use the *Private* toggle to lock access to the tool to only the creator of the environment.
 
        In the *Runtime Settings*:
 
        1. Press *Commands and Arguments* to add special commands and arguments to your environment selection.
        2. Press *Environment variable* to add an environment variable. Press again if you need more environment variables.
 
-4. In the *Compute resource* pane, select a compute resource. Use the *Search compute resources* if you do not see your resource listed. Press *New compute resource* to add a new compute resource to the system. Press *More settings* to add a node type (node affinity) to the compute resource selected.
-5. (Optional) In the *Volume* pane, press *+volume* to add a new volume to the template.
+5. In the *Compute resource* pane, select a compute resource. Use the *Search compute resources* if you do not see your resource listed. Press *New compute resource* to add a new compute resource to the system. Press *More settings* to add a node type (node affinity) to the compute resource selected.
+6. (Optional) In the *Volume* pane, press *+volume* to add a new volume to the template.
 
     From the drop down menus select:
     * Storage class
@@ -34,11 +34,11 @@ To create a template:
 
     Set the *Volume target location*, then select from either a *Persistent* volume or an *Ephemeral* volume.
 
-6. In the *Data sources* pane, select a data source. Press *New data source* to add a new data source to the system.
-7. In the *General* pane, choose to add the following:
+7. In the *Data sources* pane, select a data source. Press *New data source* to add a new data source to the system.
+8. In the *General* pane, choose to add the following:
 
     * Auto-deletion—the time after which a workload that has completed or failed will be deleted. Press *+Auto-deletion* then configure the time in days, hours, minutes, and seconds.
     * Annotation—press *+Annottion* then enter a name and a value. You can add multiple annotations by pressing the *+Annottion*.
     * Label—press *+Label* then enter a name and a value. You can add multiple labels by pressing the *+Label*.
 
-8. Press *Create template* when your configuration is complete.
+9. Press *Create template* when your configuration is complete.

docs/admin/runai-setup/cluster-setup/cluster-prerequisites.md

@@ -73,7 +73,7 @@ For Run:ai on OpenShift to run with PSA `restricted` policy:
    pod-security.kubernetes.io/enforce=privileged
    pod-security.kubernetes.io/warn=privileged
    ```
-2. The workloads submitted through Run:ai should comply with the restrictions of PSA `restricted` policy, which are dropping all Linux capabilities and setting `runAsNonRoot` to `true`. This can be done and enforced using [Policies](../../workloads/policies.md).
+2. The workloads submitted through Run:ai should comply with the restrictions of PSA `restricted` policy, which are dropping all Linux capabilities and setting `runAsNonRoot` to `true`. This can be done and enforced using [Policies](../../workloads/policies/policies.md).
 
 ### NVIDIA
 

docs/admin/runai-setup/config/non-root-containers.md

@@ -5,23 +5,23 @@ The identity of the user in the container determines its access to resources. Fo
 
 ## The Default: Root Access
 
-In docker, as well as in Kubernetes, the default for running containers is running as _root_. The implication of running as root is that processes running within the container have enough permissions to change anything in the container, and if propagated to network resources - can have permissions outside the container as well. 
+In docker, as well as in Kubernetes, the default for running containers is running as _root_. The implication of running as root is that processes running within the container have enough permissions to change anything in the container, and if propagated to network resources - can have permissions outside the container as well.
 
-This gives a lot of power to the Researcher but does not sit well with modern security standards of enterprise security. 
+This gives a lot of power to the Researcher but does not sit well with modern security standards of enterprise security.
 
 By default, if you run:
 
 ```
 runai submit -i ubuntu --attach --interactive -- bash
 ```
-then run `id`, you will see the **root** user. 
+then run `id`, you will see the **root** user.
 
 ## Use Run:ai flags to limit root access
 
 There are two [runai submit](../../../Researcher/cli-reference/runai-submit.md) flags which control user identity at the Researcher level:
 
-* The flag `--run-as-user` starts the container with a specific user. The user is the current Linux user (see below for other behaviors if used in conjunction with Single sign-on). 
-* The flag `--prevent-privilege-escalation` prevents the container from elevating its own privileges into `root` (e.g. running `sudo` or changing system files.). 
+* The flag `--run-as-user` starts the container with a specific user. The user is the current Linux user (see below for other behaviors if used in conjunction with Single sign-on).
+* The flag `--prevent-privilege-escalation` prevents the container from elevating its own privileges into `root` (e.g. running `sudo` or changing system files.).
 
 Equivalent flags exist in the Researcher User Interface.
 ### Run as Current User
@@ -44,16 +44,16 @@ runai submit -i ubuntu --attach --interactive --run-as-user \
   --prevent-privilege-escalation  -- bash
 ```
 
-then verify that you cannot run `su` to become root within the container. 
+then verify that you cannot run `su` to become root within the container.
 
 
 ### Setting a Cluster-Wide Default
 
 
-The two flags are voluntary. They are not enforced by the system. It is however possible to enforce them using [Policies](../../workloads/policies.md). Polices allow an Administrator to force compliance on both the User Interface and Command-line interface. 
+The two flags are voluntary. They are not enforced by the system. It is however possible to enforce them using [Policies](../../workloads/policies/policies.md). Polices allow an Administrator to force compliance on both the User Interface and Command-line interface.
 
 
-## Passing user identity 
+## Passing user identity
 ### Passing user identity from Identity Provider
 
 A best practice is to store the user identifier (UID) and the group identifier (GID) in the organization's directory. Run:ai allows you to pass these values to the container and use them as the container identity.
@@ -67,7 +67,7 @@ To perform this, you must:
 Running `id` should show the identifier from the directory.
 
 
-### Passing user identity explicitly via the Researcher UI 
+### Passing user identity explicitly via the Researcher UI
 
 Via the Researcher User Interface, it is possible to explicitly provide the user id and group id:
 
@@ -78,7 +78,7 @@ Via the Researcher User Interface, it is possible to explicitly provide the user
 
 
 Run:ai supports OpenShift as a Kubernetes platform. In OpenShift the system will provide a __random__ UID to containers. The flags `--run-as-user` and `--prevent-privilege-escalation` are disabled on OpenShift.
-It is possible to achieve a similar effect on Kubernetes systems that are not OpenShift. A leading tool is [Gatekeeper](https://open-policy-agent.github.io/gatekeeper/website/docs/){target=_blank}. Gatekeeper similarly enforces non-root on containers at the system level. 
+It is possible to achieve a similar effect on Kubernetes systems that are not OpenShift. A leading tool is [Gatekeeper](https://open-policy-agent.github.io/gatekeeper/website/docs/){target=_blank}. Gatekeeper similarly enforces non-root on containers at the system level.
 
 
 ## Creating a Temporary Home Directory
@@ -99,7 +99,7 @@ I have no name!@job-0-0-0:/$
 Adding home directories to an image per user is not a viable solution. To overcome this, Run:ai provides an additional flag `--create-home-dir`. Adding this flag creates a temporary home directory for the user within the container.  
 
 !!! Notes
-    * Data saved in this directory will not be saved when the container exits. 
+    * Data saved in this directory will not be saved when the container exits.
     * This flag is set by __default to true__ when the `--run-as-user` flag is used, and false if not.
 
 

docs/admin/workloads/policies/policies.md

@@ -288,7 +288,7 @@ When submitting a workload that is affected by this policy, the created containe
 the namespace where the workload runs.
 
 !!! Note
-    Run:ai provides a secret propagation mechanism from the `runai` namespace to all project namespaces. For further information see [secret propagation](secrets.md#secrets-and-projects)
+    Run:ai provides a secret propagation mechanism from the `runai` namespace to all project namespaces. For further information see [secret propagation](../secrets.md#secrets-and-projects).
 
 ### Prevent Data Storage on the Node
 
@@ -362,7 +362,7 @@ To access _project-specific_ policies, replace the `-n runai` parameter with the
 
 ## See Also
 
-* For creating workloads based on policies, see the Run:ai [submitting workloads](../../developer/cluster-api/workload-overview-dev.md)
+* For creating workloads based on policies, see the Run:ai [submitting workloads](../../../developer/cluster-api/workload-overview-dev.md)
 
 **API LINK HERE!!!!!!!!**
 

docs/admin/workloads/policies/training-policy.md

@@ -49,12 +49,12 @@ To create a policy:
 !!! Note
     After saving, the form will wait for the policy to sync with the cluster.
 
---8<-- "../docs/snippets/snippets-policies.md:1:170"
+--8<-- "snippets-policies.md:1:170"
 
 #### Training
 
---8<-- "../docs/snippets/snippets-policies.md:172:775"
+--8<-- "snippets-policies.md:172:775"
 
 #### Training
 
---8<-- "../docs/snippets/snippets-policies.md:777:843"
+--8<-- "snippets-policies.md:777:843"

docs/admin/workloads/secrets.md

@@ -2,13 +2,13 @@
 
 ## Kubernetes Secrets
 
-Sometimes you want to use sensitive information within your code. For example passwords, OAuth tokens, or ssh keys. The best practice for saving such information in Kubernetes is via __Kubernetes Secrets__. Kubernetes Secrets let you store and manage sensitive information. Access to secrets is limited via configuration.
+Sometimes you want to use sensitive information within your code. For example passwords, OAuth tokens, or ssh keys. The best practice for saving such information in Kubernetes is via **Kubernetes Secrets**. Kubernetes Secrets let you store and manage sensitive information. Access to secrets is limited via configuration.
 
-A Kubernetes secret may hold multiple __key - value__ pairs.
+A Kubernetes secret may hold multiple **key - value** pairs.
 
 ## Using Secrets in Run:ai Workloads
 
-Our goal is to provide Run:ai Workloads with secrets as input in a secure way. Using the Run:ai command line, you will be able to pass a reference to a secret that already exists in Kubernetes. 
+Our goal is to provide Run:ai Workloads with secrets as input in a secure way. Using the Run:ai command line, you will be able to pass a reference to a secret that already exists in Kubernetes.
 
 ## Creating a secret
 
@@ -74,4 +74,4 @@ runai-adm remove secret <secret name> --cluster-wide
 
 ## Secrets and Policies
 
-A Secret can be set at the policy level. For additional information see [policies guide](policies.md)
+A Secret can be set at the policy level. For additional information see [policies guide](../workloads/policies/policies.md).

docs/admin/workloads/submitting-workloads.md

@@ -95,4 +95,4 @@ To submit a workload using the UI:
 
 ## Workload Policies
 
-As an administrator, you can set *Policies* on Workloads.  Policies allow administrators to *impose restrictions* and set *default values* for Researcher Workloads. For more information see [Workload Policies](policies.md).
+As an administrator, you can set *Policies* on Workloads.  Policies allow administrators to *impose restrictions* and set *default values* for Researcher Workloads. For more information see [Workload Policies](../workloads/policies/policies.md).