remove nontenant from docs

Signed-off-by: Ruben Vargas <[email protected]>

Author: rubenvp8510

modules/distr-tracing-tempo-config-multitenancy.adoc

@@ -87,12 +87,16 @@ spec:
       name: minio-test
       type: s3
   storageSize: 1Gi
+  tenants:
+    mode: openshift 
+    authentication: 
+      - tenantName: dev 
+        tenantId: "1610b0c3-c509-4592-a256-a1871353dbfa" 
   template:
     gateway:
-      enabled: false
+      enabled: true
     queryFrontend:
       jaegerQuery:
-        enabled: true
         monitorTab:
           enabled: true # <1>
           prometheusEndpoint: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 # <2>

modules/distr-tracing-tempo-config-spanmetrics.adoc

@@ -3,15 +3,17 @@
 // * observability/distr_tracing/distr_tracing_tempo/distr-tracing-tempo-installing.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="distr-tracing-tempo-install-tempostack-web-console_{context}"]
+[id="distr-tracing-tempo-install-gateway-permissions{context}"]
 = Configure tenants and permissions
 
 Authentication and authorization is provided in the Tempo Gateway service. The authentication uses OpenShift OAuth and the Kubernetes `TokenReview` API. The authorization uses the Kubernetes `SubjectAccessReview` API.
 
-To properly define tenants and manage their read and write access, the distributed tracing stack—built on the Red Hat distribution of OpenTelemetry and Tempo—requires a well-configured authorization setup. This setup relies on Kubernetes Role-Based Access Control (RBAC) through ClusterRole and ClusterRoleBinding. By default, no users are granted read or write permissions, ensuring a secure baseline until explicit configurations are defined.
+To properly define tenants and manage their read and write access, the distributed tracing stack—built on the Red Hat distribution of OpenTelemetry and Tempo—requires a well-configured authorization setup. 
 
+This setup relies on Kubernetes Role-Based Access Control (RBAC) through ClusterRole and ClusterRoleBinding. By default, no users are granted read or write permissions, ensuring a secure baseline until explicit configurations are defined.
 
-You can install a Configure thosep permissionns from the *Administrator* view of the web console.
+
+You can install a Configure those permissionns from the *Administrator* view of the web console or using command line CLI.
 
 .Prerequisites
 
@@ -24,6 +26,7 @@ To grant users permission to read a specific tenant, follow these steps:
 
 . Define desired tenant name and tenant Id. 
 . Enable tenants to read traces by adding them to a `ClusterRole` and giving them read (get) permissions
+
 .Sample of the read RBAC configuration that allows authenticated users to read the trace data of the `dev` and `prod` tenants
 [source,yaml]
 ----
@@ -73,8 +76,9 @@ metadata:
   name: otel-collector # <1>
   namespace: otel
 ----
-. Grant the OpenTelemetry Collector write permissions by defining a ClusterRoleBinding to the previously defined role and attaching it to the ServiceAccount
-the following is a sample on how to write RBAC configuration that allows the `otel-collector` service account to write the trace data for the `dev` tenant
+. Grant the OpenTelemetry Collector write permissions by defining a Role with write permissions and  ClusterRoleBinding to attach the OpenTelemetry Collector ServiceAccount.
+
+The following is a sample on how to write RBAC configuration that allows the `otel-collector` ServiceAccount to write the trace data for the `dev` tenant
 +
 [source,yaml]
 ----
@@ -115,15 +119,15 @@ subjects:
   * Enable TLS with a valid certificate authority file.
 
 Trace data can be sent to the Tempo instance from the OpenTelemetry Collector that uses the service account with RBAC for writing the data.
-
++
 .Sample OpenTelemetry CR configuration
 [source,yaml]
 ----
 apiVersion: opentelemetry.io/v1alpha1
 kind: OpenTelemetryCollector
 metadata:
   name: cluster-collector
-  namespace: tracing-system
+  namespace: <project_of_tempostack_instance>
 spec:
   mode: deployment
   serviceAccount: otel-collector # <1>
@@ -133,7 +137,7 @@ spec:
           filename: "/var/run/secrets/kubernetes.io/serviceaccount/token"
       exporters:
         otlp/dev: # <3>
-          endpoint: tempo-simplest-gateway.tempo.svc.cluster.local:8090
+          endpoint: sample-gateway.tempo.svc.cluster.local:8090
           tls:
             insecure: false
             ca_file: "/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt" # <4>
@@ -142,7 +146,7 @@ spec:
           headers:
             X-Scope-OrgID: "dev" <5>
         otlphttp/dev: # <6>
-          endpoint: https://tempo-simplest-gateway.chainsaw-multitenancy.svc.cluster.local:8080/api/traces/v1/dev
+          endpoint: https://sample-gateway.<project_of_tempostack_instance>.svc.cluster.local:8080/api/traces/v1/dev
           tls:
             insecure: false
             ca_file: "/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt"

modules/distr-tracing-tempo-install-gateway-permissions.adoc

@@ -73,48 +73,6 @@ You can create multiple TempoStack instances in separate projects on the same cl
 include::snippets/distr-tracing-tempo-tempostack-custom-resource.adoc[]
 --
 +
-.Example of a `TempoStack` CR for AWS S3 and MinIO storage and tenants  `dev` and `prod`
-[source,yaml]
-----
-apiVersion: tempo.grafana.com/v1alpha1
-kind:  TempoStack
-metadata:
-  name: simplest
-  namespace: chainsaw-multitenancy
-spec:
-  storage:
-    secret:  # <1>
-      name: minio
-      type: s3
-  storageSize: 1Gi
-  resources:
-    total:
-      limits:
-        memory: 2Gi
-        cpu: 2000m
-  tenants:
-    mode: openshift # <2>
-    authentication: # <3>
-      - tenantName: dev # <4>
-        tenantId: "1610b0c3-c509-4592-a256-a1871353dbfa" # <5>
-      - tenantName: prod
-        tenantId: "1610b0c3-c509-4592-a256-a1871353dbfb"
-  template:
-    gateway:
-      enabled: true # <6>
-    queryFrontend:
-      jaegerQuery:
-        enabled: true # <7>
-----
-<1> In this example, the object storage was set up as one of the prerequisites, and the object storage secret was created in step 2.
-<2> Tenant mode must be set to `openshift`.
-<3> The list of tenants.
-<4> The tenant name. Must be provided in the `X-Scope-OrgId` header when ingesting the data.
-<5> Defines a universally unique identifier of the tenant. Unlike the tenantName, which must be unique at a given time, the tenantId must be unique over the entire lifetime of the Tempo deployment. Tempo uses this ID to prefix objects in the object storage. This could be a UUID, or can match the tempoName
-<6> Enables a gateway that performs authentication and authorization. The Jaeger UI is exposed at `http://<gateway-ingress>/api/traces/v1/<tenant-name>/search`.
-<7> The stack deployed in this example is configured to receive Jaeger Thrift over HTTP and OpenTelemetry Protocol (OTLP), which permits visualizing the data with the Jaeger UI.
-
-
 .. Apply the customized CR by running the following command:
 +
 [source,terminal]

modules/distr-tracing-tempo-install-tempostack-cli.adoc

@@ -51,8 +51,6 @@ include::modules/distr-tracing-tempo-config-receiver-tls-for-tempomonolithic.ado
 * xref:../../../security/certificates/service-serving-certificate.adoc#understanding-service-serving_service-serving-certificate[Understanding service serving certificates]
 * xref:../../../security/certificate_types_descriptions/service-ca-certificates.adoc#cert-types-service-ca-certificates[Service CA certificates] 
 
-include::modules/distr-tracing-tempo-config-multitenancy.adoc[leveloffset=+1]
-
 [id="taints-and-tolerations_{context}"]
 == Using taints and tolerations