Merge pull request #59331 from mburke5678/cma-edits-zbynek

CMA edits per Zbynek Roubalik

Author: mburke5678

modules/nodes-pods-autoscaling-custom-about.adoc

@@ -12,7 +12,7 @@ To use the custom metrics autoscaler, you create a `ScaledObject` or `ScaledJob`
 
 [NOTE]
 ====
-You can create only one scaled object or scaled job for each workload that you want to scale. Also, you cannot use a scaled object or scaled job and the horizontal pod autoscaler (HPA) on the same workload.
+You can create only one scaled object for each workload that you want to scale. Also, you cannot use a scaled object and the horizontal pod autoscaler (HPA) on the same workload.
 ==== 
 
 The custom metrics autoscaler, unlike the HPA, can scale to zero. If you set the `minReplicaCount` value in the custom metrics autoscaler CR to `0`, the custom metrics autoscaler scales the workload down from 1 to 0 replicas to or up from 0 replicas to 1. This is known as the _activation phase_. After scaling up to 1 replica, the HPA takes control of the scaling. This is known as the _scaling phase_. 

modules/nodes-pods-autoscaling-custom-adding.adoc

@@ -8,7 +8,7 @@
 
 To add a custom metrics autoscaler, create a `ScaledObject` custom resource for a deployment, stateful set, or custom resource. Create a `ScaledJob` custom resource for a job.
 
-You can create only one scaled object or scaled job for each workload that you want to scale. Also, you cannot use a scaled object or scaled job and the horizontal pod autoscaler (HPA) on the same workload. 
+You can create only one scaled object for each workload that you want to scale. Also, you cannot use a scaled object and the horizontal pod autoscaler (HPA) on the same workload.
 
 // If you want to scale based on a custom trigger and CPU/Memory, you can create multiple triggers in the scaled object or scaled job.
 

modules/nodes-pods-autoscaling-custom-creating-job.adoc

@@ -8,6 +8,9 @@
 
 You can create a custom metrics autoscaler for any `Job` object.
 
+:FeatureName: Scaling by using a scaled job
+include::snippets/technology-preview.adoc[]
+
 .Prerequisites
 
 * The Custom Metrics Autoscaler Operator must be installed. 

modules/nodes-pods-autoscaling-custom-creating-workload.adoc

@@ -123,7 +123,7 @@ spec:
       metricName: http_requests_total
       threshold: '5'
       query: sum(rate(http_requests_total{job="test-app"}[1m]))
-      authModes: "basic"
+      authModes: basic
   - authenticationRef: <17>
       name: prom-triggerauthentication
     metadata:

modules/nodes-pods-autoscaling-custom-pausing.adoc

@@ -44,8 +44,8 @@ metadata:
   generation: 1
   name: scaledobject
   namespace: my-project
-  resourceVersion: "65729"
-  uid: f5aec682-acdf-4232-a783-58b5b82f5dd0
+  resourceVersion: '65729'
+  uid: 'f5aec682-acdf-4232-a783-58b5b82f5dd0'
 ----
 <1> Specifies that the Custom Metrics Autoscaler Operator is to scale the replicas to the specified value and stop autoscaling.
 

modules/nodes-pods-autoscaling-custom-trigger.adoc

@@ -45,16 +45,16 @@ spec:
       metricName: http_requests_total <4>
       threshold: '5' <5>
       query: sum(rate(http_requests_total{job="test-app"}[1m])) <6>
-      authModes: "basic" <7>
+      authModes: basic <7>
       cortexOrgID: my-org <8>
       ignoreNullValues: false <9>
-      unsafeSsl: "false" <10>
+      unsafeSsl: false <10>
 ----
 <1> Specifies Prometheus as the scaler/trigger type.
 <2> Specifies the address of the Prometheus server. This example uses  {product-title} monitoring.
 <3> Optional: Specifies the namespace of the object you want to scale. This parameter is mandatory if {product-title} monitoring as a source for the metrics.
 <4> Specifies the name to identify the metric in the `external.metrics.k8s.io` API. If you are using more than one trigger, all metric names must be unique.
-<5> Specifies the value to start scaling for.
+<5> Specifies the value to start scaling for. Must be specified as a quoted string value.
 <6> Specifies the Prometheus query to use.
 <7> Specifies the authentication method to use. Prometheus scalers support bearer authentication (`bearer`), basic authentication (`basic`), or TLS authentication (`tls`). You configure the specific authentication parameters in a trigger authentication, as discussed in a following section. As needed, you can also use a secret.
 <8> Optional: Passes the `X-Scope-OrgID` header to multi-tenant link:https://cortexmetrics.io/[Cortex] or link:https://grafana.com/oss/mimir/[Mimir] storage for Prometheus. This parameter is required only with multi-tenant Prometheus storage, to indicate which data Prometheus should return. 
@@ -94,13 +94,13 @@ spec:
   - type: cpu <1>
     metricType: Utilization <2>
     metadata:
-      value: "60" <3>
-      containerName: "api" <4>
+      value: '60' <3>
+      containerName: api <4>
 
 ----
 <1> Specifies CPU as the scaler/trigger type.
 <2> Specifies the type of metric to use, either `Utilization` or `AverageValue`.
-<3> Specifies the value to trigger scaling actions upon:
+<3> Specifies the value to trigger scaling actions. Must be specified as a quoted string value.
 * When using `Utilization`, the target value is the average of the resource metrics across all relevant pods, represented as a percentage of the requested value of the resource for the pods.
 * When using `AverageValue`, the target value is the average of the metrics across all relevant pods.
 <4> Optional. Specifies an individual container to scale, based on the memory utilization of only that container, rather than the entire pod. Here, only the container named `api` is to be scaled.
@@ -134,12 +134,12 @@ spec:
   - type: memory <1>
     metricType: Utilization <2>
     metadata:
-      value: "60" <3>
-      containerName: "api" <4>
+      value: '60' <3>
+      containerName: api <4>
 ----
 <1> Specifies memory as the scaler/trigger type.
 <2> Specifies the type of metric to use, either `Utilization` or `AverageValue`.
-<3> Specifies the value to trigger scaling actions for:
+<3> Specifies the value to trigger scaling actions. Must be specified as a quoted string value.
 * When using `Utilization`, the target value is the average of the resource metrics across all relevant pods, represented as a percentage of the requested value of the resource for the pods.
 * When using `AverageValue`, the target value is the average of the metrics across all relevant pods.
 <4> Optional. Specifies an individual container to scale, based on the memory utilization of only that container, rather than the entire pod. Here, only the container named `api` is to be scaled.
@@ -179,20 +179,20 @@ spec:
       bootstrapServers: my-cluster-kafka-bootstrap.openshift-operators.svc:9092 <3>
       consumerGroup: my-group <4>
       lagThreshold: '10' <5>
-      activationLagThreshold <6>
-      offsetResetPolicy: 'latest' <7>
+      activationLagThreshold: '5' <6>
+      offsetResetPolicy: latest <7>
       allowIdleConsumers: true <8>
       scaleToZeroOnInvalidOffset: false <9>
       excludePersistentLag: false <10>
-      version: 1.0.0 <11>
+      version: '1.0.0' <11>
       partitionLimitation: '1,2,10-20,31' <12>
 ----
 <1> Specifies Kafka as the scaler/trigger type.
 <2> Specifies the name of the Kafka topic on which Kafka is processing the offset lag.
 <3> Specifies a comma-separated list of Kafka brokers to connect to.
 <4> Specifies the name of the Kafka consumer group used for checking the offset on the topic and processing the related lag.
-<5> Optional: Specifies the average target value to trigger scaling actions. The default is `5`.
-<6> Optional: Specifies the target value for the activation phase.
+<5> Optional: Specifies the average target value to trigger scaling actions. Must be specified as a quoted string value. The default is `5`. 
+<6> Optional: Specifies the target value for the activation phase. Must be specified as a quoted string value. The default is `0`.
 <7> Optional: Specifies the Kafka offset reset policy for the Kafka consumer. The available values are: `latest` and `earliest`. The default is `latest`.
 <8> Optional: Specifies whether the number of Kafka replicas can exceed the number of partitions on a topic.
      * If `true`, the number of Kafka replicas can exceed the number of partitions on a topic. This allows for idle Kafka consumers.
@@ -203,6 +203,6 @@ spec:
 <10> Optional: Specifies whether the trigger includes or excludes partition lag for partitions whose current offset is the same as the current offset of the previous polling cycle.
       * If `true`, the scaler excludes partition lag in these partitions.
       * If `false`, the trigger includes all consumer lag in all partitions. This is the default.
-<11> Optional: Specifies the version of your Kafka brokers. The default is `1.0.0`.
-<12> Optional: Specifies a comma-separated list of partition IDs to scope the scaling on. If set, only the listed IDs are considered when calculating lag. The default is to consider all partitions.
+<11> Optional: Specifies the version of your Kafka brokers. Must be specified as a quoted string value. The default is `1.0.0`.
+<12> Optional: Specifies a comma-separated list of partition IDs to scope the scaling on. If set, only the listed IDs are considered when calculating lag. Must be specified as a quoted string value. The default is to consider all partitions.
 

nodes/pods/nodes-pods-autoscaling-custom.adoc

@@ -8,6 +8,9 @@ toc::[]
 
 As a developer, you can use the custom metrics autoscaler to specify how {product-title} should automatically increase or decrease the number of pods for a deployment, stateful set, custom resource, or job based on custom metrics that are not based only on CPU or memory.
 
+:FeatureName: Scaling by using a scaled job
+include::snippets/technology-preview.adoc[]
+
 The Custom Metrics Autoscaler Operator for Red Hat OpenShift is an optional operator, based on the Kubernetes Event Driven Autoscaler (KEDA), that allows workloads to be scaled using additional metrics sources other than pod metrics.
 
 [NOTE]
@@ -17,9 +20,6 @@ The custom metrics autoscaler currently supports only the Prometheus, CPU, memor
 
 // For example, you can scale a database application based on the number of tables in the database, scale another application based on the number of messages in a Kafka topic, or scale based on incoming HTTP requests collected by {product-title} monitoring.
 
-:FeatureName: The custom metrics autoscaler
-include::snippets/technology-preview.adoc[leveloffset=+0]
-
 // The following include statements pull in the module files that comprise
 // the assembly. Include any combination of concept, procedure, or reference
 // modules required to cover the user story. You can also include other