Fix typos in random docs

setup/otel/collector.md

@@ -165,7 +165,7 @@ The `service` section determines what components of the collector are enabled. T
 The `pipelines` section defines pipelines for the traces and metrics. The metrics pipeline defines:
 * `receivers`, to receive metrics from instrumented applications (via the OTLP protocol, `otlp`), from spans (the `spanmetrics` connector) and by scraping Prometheus endpoints (the `prometheus` receiver). The latter is configured by default in the collector Helm chart to scrape the collectors own metrics
 * `processors`: The `memory_limiter` helps to prevent out-of-memory errors. The `batch` processor helps better compress the data and reduce the number of outgoing connections required to transmit the data. The `resource` processor adds additional resource attributes (discussed separately)
-* `exporters`: The `debug` exporter simply logs to stdout which helps when troubleshooting. The `otlp/stackstate` exporter sends telemetry data to SUSE Observability using the OTLP protocol via GRPC (Default). The `otlphttp/stackstate` exporter sends telemetry data to SUSE Observability using the OTLP protocol via HTTP and is meant to be used where there area some impediments to use the GRPC one (Needs to be activated in the pipelineS). Both OTLP exporters are configured to use the bearertokenauth extension for authentication to send data to the SUSE Observability OTLP endpoint.
+* `exporters`: The `debug` exporter simply logs to stdout which helps when troubleshooting. The `otlp/stackstate` exporter sends telemetry data to SUSE Observability using the OTLP protocol via GRPC (Default). The `otlphttp/stackstate` exporter sends telemetry data to SUSE Observability using the OTLP protocol via HTTP and is meant to be used where there area some impediments to use the GRPC one (needs to be activated in the pipelines). Both OTLP exporters are configured to use the bearertokenauth extension for authentication to send data to the SUSE Observability OTLP endpoint.
 
 For traces, there are 3 pipelines that are connected:
 * `traces`: The pipeline that receives traces from SDKs (via the `otlp` receiver) and does the initial processing using the same processors as for metrics. It exports into a router which routes all spans to both other traces pipelines. This setup makes it possible to calculate span metrics for all spans while applying sampling to the traces that are exported.

setup/security/authentication/oidc.md

@@ -41,11 +41,12 @@ stackstate:
         access_type: offline
 
     # map the groups from OIDC provider
-    # to the 4 standard roles in SUSE Observability (guest, powerUser and admin)
+    # to the 4 standard roles in SUSE Observability (guest, powerUser, k8sTroubleshooter and admin)
     roles:
       guest: ["oidc-guest-role-for-stackstate"]
       powerUser: ["oidc-power-user-role-for-stackstate"]
       admin: ["oidc-admin-role-for-stackstate"]
+      k8sTroubleshooter: ["oidc-troubleshooter-role-for-stackstate"]
 ```
 
 Follow the steps below to configure SUSE Observability to authenticate using OIDC:

setup/security/authentication/single_password.md

@@ -4,7 +4,7 @@ description: SUSE Observability Self-hosted
 
 # Single password
 
-Out of the box, SUSE Observability is configured with a single password configuration, [configured during installation](/k8s-suse-rancher-prime.md#installation). This authenticates users with a single, randomly generated password created by the `sus-observability-values` chart.
+Out of the box, SUSE Observability is configured with a single password configuration, [configured during installation](/k8s-suse-rancher-prime.md#installation). This authenticates users with a single, randomly generated password created by the `suse-observability-values` chart.
 The password value can be found as comment in the generated `suse-observability-values/templates/baseConfig_values.yaml`.
 
 This setup provisions an admin user with the generated password