Merge pull request #77944 from max-cx/OBSDOCS-1065

OBSDOCS-1065: Troubleshoot and correct YAML block copy-and-paste functionality

Author: ShaunaDiaz

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

@@ -32,86 +32,86 @@ spec:
 
 .Tempo parameters
 [options="header"]
-[cols="l, a, a, a"]
+[cols="a, a, a, a"]
 |===
 |Parameter |Description |Values |Default value
 
-|apiVersion:
+|`apiVersion:`
 |API version to use when creating the object.
 |`tempo.grafana.com/v1alpha1`
 |`tempo.grafana.com/v1alpha1`
 
-|kind:
+|`kind:`
 |Defines the kind of Kubernetes object to create.
 |`tempo`
 |
 
-|metadata:
+|`metadata:`
 |Data that uniquely identifies the object, including a `name` string, `UID`, and optional `namespace`.
 |
 |{product-title} automatically generates the `UID` and completes the `namespace` with the name of the project where the object is created.
 
-|name:
+|`name:`
 |Name for the object.
 |Name of your TempoStack instance.
 |`tempo-all-in-one-inmemory`
 
-|spec:
+|`spec:`
 |Specification for the object to be created.
 |Contains all of the configuration parameters for your TempoStack instance. When a common definition for all Tempo components is required, it is defined under the `spec` node. When the definition relates to an individual component, it is placed under the `spec/template/<component>` node.
 |N/A
 
-|resources:
+|`resources:`
 |Resources assigned to the TempoStack instance.
 |
 |
 
-|storageSize:
+|`storageSize:`
 |Storage size for ingester PVCs.
 |
 |
 
-|replicationFactor:
+|`replicationFactor:`
 |Configuration for the replication factor.
 |
 |
 
-|retention:
+|`retention:`
 |Configuration options for retention of traces.
 |
 |
 
-|storage:
+|`storage:`
 |Configuration options that define the storage. All storage-related options must be placed under `storage` and not under the `allInOne` or other component options.
 |
 |
 
-|template.distributor:
+|`template.distributor:`
 |Configuration options for the Tempo `distributor`.
 |
 |
 
-|template.ingester:
+|`template.ingester:`
 |Configuration options for the Tempo `ingester`.
 |
 |
 
-|template.compactor:
+|`template.compactor:`
 |Configuration options for the Tempo `compactor`.
 |
 |
 
-|template.querier:
+|`template.querier:`
 |Configuration options for the Tempo `querier`.
 |
 |
 
-|template.queryFrontend:
+|`template.queryFrontend:`
 |Configuration options for the Tempo `query-frontend`.
 |
 |
 
-|template.gateway:
+|`template.gateway:`
 |Configuration options for the Tempo `gateway`.
 |
 |

modules/distr-tracing-tempo-config-query-frontend.adoc

@@ -11,7 +11,7 @@ Two components of the {TempoShortName}, the querier and query frontend, manage q
 The querier component finds the requested trace ID in the ingesters or back-end storage. Depending on the set parameters, the querier component can query both the ingesters and pull bloom or indexes from the back end to search blocks in object storage. The querier component exposes an HTTP endpoint at `GET /querier/api/traces/<trace_id>`, but it is not expected to be used directly. Queries must be sent to the query frontend.
 
 .Configuration parameters for the querier component
-[options="header",cols="l, a, a]
+[options="header",cols="a, a, a]
 |===
 |Parameter |Description |Values
 
@@ -31,7 +31,7 @@ The querier component finds the requested trace ID in the ingesters or back-end
 The query frontend component is responsible for sharding the search space for an incoming query. The query frontend exposes traces via a simple HTTP endpoint: `GET /api/traces/<trace_id>`. Internally, the query frontend component splits the `blockID` space into a configurable number of shards and then queues these requests. The querier component connects to the query frontend component via a streaming gRPC connection to process these sharded queries.
 
 .Configuration parameters for the query frontend component
-[options="header",cols="l, a, a]
+[options="header",cols="a, a, a]
 |===
 |Parameter |Description |Values
 

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

@@ -77,7 +77,7 @@ The `TempoStack` custom resource must specify the following: the *Monitor* tab i
 .TempoStack custom resource with the enabled Monitor tab
 [source,yaml]
 ----
-kind:  TempoStack
+kind: TempoStack
 apiVersion: tempo.grafana.com/v1alpha1
 metadata:
   name: simplest
@@ -102,21 +102,21 @@ The metrics generated by the `spanmetrics` connector are usable with alerting ru
 
 .Labels of the metrics created in the `spanmetrics` connector
 [options="header"]
-[cols="l, a, a"]
+[cols="a, a, a"]
 |===
 |Label |Description |Values
 
-|service_name
+|`service_name`
 |Service name set by the `otel_service_name` environment variable.
 |`frontend`
 
-|span_name
+|`span_name`
 | Name of the operation.
 |
 * `/`
 * `/customer`
 
-|span_kind
+|`span_kind`
 |Identifies the server, client, messaging, or internal operation.
 |
 * `SPAN_KIND_SERVER`

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

@@ -11,26 +11,20 @@ You can configure object storage for the {TempoShortName} in the `TempoStack` cu
 
 .General storage parameters used by the {TempoOperator} to define distributed tracing storage
 [options="header"]
-[cols="l, a, a, a"]
+[cols="a, a, a, a"]
 |===
 |Parameter |Description |Values |Default value
-|spec:
-  storage:
-    secret
-      type:
+|`spec.storage.secret.type`
 |Type of storage to use for the deployment.
 |`memory`. Memory storage is only appropriate for development, testing, demonstrations, and proof of concept environments because the data does not persist when the pod is shut down.
 |`memory`
 
-|storage:
-  secretname:
+|`storage.secretname`
 |Name of the secret that contains the credentials for the set object storage type.
 |
 |N/A
 
-|storage:
-  tls:
-    caName:
+|`storage.tls.caName`
 |CA is the name of a `ConfigMap` object containing a CA certificate.
 |
 |