Updating notes

docs/en/logging/custom-resource-config/outputs/outputs.md

@@ -211,7 +211,11 @@ spec:
 
 For the final example, we create an `Output` to write logs to a destination that is not supported out of the box:
 
-> **Note on syslog** `syslog` is a supported `Output`. However, this example still provides an overview on using unsupported plugins.
+:::note Note on syslog:
+
+`syslog` is a supported `Output`. However, this example still provides an overview on using unsupported plugins.
+
+:::
 
 ```yaml
 apiVersion: v1

docs/en/logging/helm-chart-options/helm-chart-options.md

@@ -20,7 +20,11 @@ By default, Windows node logging will be enabled if the Cluster Dashboard UI is
 In this scenario, setting `global.cattle.windows.enabled` to `false` will disable Windows node logging on the cluster.
 When disabled, logs will still be collected from Linux nodes within the Windows cluster.
 
-> Note: Currently an [issue](https://github.com/rancher/rancher/issues/32325) exists where Windows nodeAgents are not deleted when performing a `helm upgrade` after disabling Windows logging in a Windows cluster. In this scenario, users may need to manually remove the Windows nodeAgents if they are already installed.
+:::note
+
+Currently an [issue](https://github.com/rancher/rancher/issues/32325) exists where Windows nodeAgents are not deleted when performing a `helm upgrade` after disabling Windows logging in a Windows cluster. In this scenario, users may need to manually remove the Windows nodeAgents if they are already installed.
+
+:::
 
 ### Working with a Custom Docker Root Directory
 
@@ -38,7 +42,11 @@ You can add your own `nodeSelector` settings and add `tolerations` for additiona
 
 ### Enabling the Logging Application to Work with SELinux
 
-> **Requirements:** Logging v2 was tested with SELinux on RHEL/CentOS 7 and 8.
+:::note Requirements:
+
+Logging v2 was tested with SELinux on RHEL/CentOS 7 and 8.
+
+:::
 
 [Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.
 
@@ -84,8 +92,12 @@ K3s and RKE2 Kubernetes distributions log to journald, which is the subsystem of
   * If `/var/log/journal` exists, then use `/var/log/journal`. 
   * If `/var/log/journal` does not exist, then use `/run/log/journal`. 
 
-> **Note:** If any value not described above is returned, Rancher Logging will not be able to collect control plane logs. To address this issue, you will need to perform the following actions on every control plane node:
+:::note Notes:
 
-> * Set `Storage=volatile` in  journald.conf.
-> * Reboot your machine.
-> * Set `systemdLogPath` to `/run/log/journal`. 
+If any value not described above is returned, Rancher Logging will not be able to collect control plane logs. To address this issue, you will need to perform the following actions on every control plane node:
+
+* Set `Storage=volatile` in  journald.conf.
+* Reboot your machine.
+* Set `systemdLogPath` to `/run/log/journal`.
+
+:::

docs/en/logging/migrating/migrating.md

@@ -27,7 +27,11 @@ To install logging in Rancher v2.5+, refer to the [installation instructions]({{
 
 In v2.5+, logging configuration in the **Cluster Dashboard**. To configure logging custom resources after the Logging application is installed, go to the left navigation bar and click **Logging**. It is from this menu option that logging for both cluster and namespace is configured. 
 
-> Note: Logging is installed on a per-cluster basis. You will need to navigate between clusters to configure logging for each cluster. 
+:::note
+
+Logging is installed on a per-cluster basis. You will need to navigate between clusters to configure logging for each cluster. 
+
+:::
 
 There are four key concepts to understand for v2.5+ logging:
 
@@ -51,7 +55,11 @@ There are four key concepts to understand for v2.5+ logging:
 
 To configure cluster-wide logging for v2.5+ logging, one needs to set up a `ClusterFlow`. This object defines the source of logs, any transformations or filters to be applied, and finally the `Output` (or `Outputs`) for the logs. 
 
-> Important: `ClusterFlows` must be defined within the `cattle-logging-system` namespace. `ClusterFlows` will not work if defined in any other namespace. 
+:::note Important:
+
+`ClusterFlows` must be defined within the `cattle-logging-system` namespace. `ClusterFlows` will not work if defined in any other namespace.
+
+:::
 
 In legacy logging, in order to collect logs from across the entire cluster, one only needed to enable cluster-level logging and define the desired `Output`. This basic approach remains in v2.5+ logging. To replicate legacy cluster-level logging, follow these steps:
 
@@ -77,7 +85,11 @@ To collect logs from a specific namespace, follow these steps:
 
 This will result in logs from all sources in the namespace (pods) being collected and sent to the `Output` (or `Outputs`) you defined in your `Flow`.
 
-> To collect logs from a project, repeat the above steps for every namespace within the project. Alternatively, you can label your project workloads with a common label (e.g. `project=my-project`) and use a `ClusterFlow` to collect logs from all pods matching this label. 
+:::note
+
+To collect logs from a project, repeat the above steps for every namespace within the project. Alternatively, you can label your project workloads with a common label (e.g. `project=my-project`) and use a `ClusterFlow` to collect logs from all pods matching this label.
+
+:::
 
 # Output Configuration
 In legacy logging, there are five logging destinations to choose from: Elasticsearch, Splunk, Kafka, Fluentd, and Syslog. With the exception of Syslog, all of these destinations are available in logging v2.5+. 

docs/en/logging/rbac/rbac.md

@@ -9,7 +9,11 @@ Rancher logging has two roles, `logging-admin` and `logging-view`.
 - `logging-admin` gives users full access to namespaced `Flows` and `Outputs`
 - `logging-view` allows users to *view* namespaced `Flows` and `Outputs`, and `ClusterFlows` and `ClusterOutputs`
 
-> **Why choose one role over the other?** Edit access to `ClusterFlow` and `ClusterOutput` resources is powerful. Any user with it has edit access for all logs in the cluster.
+:::note Why choose one role over the other?
+
+Edit access to `ClusterFlow` and `ClusterOutput` resources is powerful. Any user with it has edit access for all logs in the cluster.
+
+:::
 
 In Rancher, the cluster administrator role is the only role with full access to all `rancher-logging` resources. Cluster members are not able to edit or read any logging resources. Project owners and members have the following privileges: