[enterprise-4.16] Custom Metrics Autoscaler compilation PR

_topic_maps/_topic_map.yml

@@ -2512,6 +2512,8 @@ Topics:
     File: nodes-cma-autoscaling-custom-trigger
   - Name: Understanding custom metrics autoscaler trigger authentications
     File: nodes-cma-autoscaling-custom-trigger-auth
+  - Name: Understanding how to add custom metrics autoscalers
+    File: nodes-cma-autoscaling-custom-adding
   - Name: Pausing the custom metrics autoscaler
     File: nodes-cma-autoscaling-custom-pausing
   - Name: Gathering audit logs
@@ -2520,8 +2522,6 @@ Topics:
     File: nodes-cma-autoscaling-custom-debugging
   - Name: Viewing Operator metrics
     File: nodes-cma-autoscaling-custom-metrics
-  - Name: Understanding how to add custom metrics autoscalers
-    File: nodes-cma-autoscaling-custom-adding
   - Name: Removing the Custom Metrics Autoscaler Operator
     File: nodes-cma-autoscaling-custom-removing
 - Name: Controlling pod placement onto nodes (scheduling)

_topic_maps/_topic_map_osd.yml

@@ -1016,6 +1016,8 @@ Topics:
     File: nodes-cma-autoscaling-custom-trigger
   - Name: Understanding the custom metrics autoscaler trigger authentications
     File: nodes-cma-autoscaling-custom-trigger-auth
+  - Name: Understanding how to add custom metrics autoscalers
+    File: nodes-cma-autoscaling-custom-adding
   - Name: Pausing the custom metrics autoscaler
     File: nodes-cma-autoscaling-custom-pausing
   - Name: Gathering audit logs
@@ -1024,8 +1026,6 @@ Topics:
     File: nodes-cma-autoscaling-custom-debugging
   - Name: Viewing Operator metrics
     File: nodes-cma-autoscaling-custom-metrics
-  - Name: Understanding how to add custom metrics autoscalers
-    File: nodes-cma-autoscaling-custom-adding
   - Name: Removing the Custom Metrics Autoscaler Operator
     File: nodes-cma-autoscaling-custom-removing
 - Name: Controlling pod placement onto nodes (scheduling)

_topic_maps/_topic_map_rosa.yml

@@ -1316,6 +1316,8 @@ Topics:
     File: nodes-cma-autoscaling-custom-trigger
   - Name: Understanding the custom metrics autoscaler trigger authentications
     File: nodes-cma-autoscaling-custom-trigger-auth
+  - Name: Understanding how to add custom metrics autoscalers
+    File: nodes-cma-autoscaling-custom-adding
   - Name: Pausing the custom metrics autoscaler
     File: nodes-cma-autoscaling-custom-pausing
   - Name: Gathering audit logs
@@ -1324,8 +1326,6 @@ Topics:
     File: nodes-cma-autoscaling-custom-debugging
   - Name: Viewing Operator metrics
     File: nodes-cma-autoscaling-custom-metrics
-  - Name: Understanding how to add custom metrics autoscalers
-    File: nodes-cma-autoscaling-custom-adding
   - Name: Removing the Custom Metrics Autoscaler Operator
     File: nodes-cma-autoscaling-custom-removing
 - Name: Controlling pod placement onto nodes (scheduling)

_topic_maps/_topic_map_rosa_hcp.yml

@@ -1226,6 +1226,8 @@ Topics:
 #     File: nodes-cma-autoscaling-custom-trigger
 #   - Name: Understanding the custom metrics autoscaler trigger authentications
 #     File: nodes-cma-autoscaling-custom-trigger-auth
+#   - Name: Understanding how to add custom metrics autoscalers
+#     File: nodes-cma-autoscaling-custom-adding
 #   - Name: Pausing the custom metrics autoscaler
 #     File: nodes-cma-autoscaling-custom-pausing
 #   - Name: Gathering audit logs
@@ -1234,8 +1236,6 @@ Topics:
 #     File: nodes-cma-autoscaling-custom-debugging
 #   - Name: Viewing Operator metrics
 #     File: nodes-cma-autoscaling-custom-metrics
-#   - Name: Understanding how to add custom metrics autoscalers
-#     File: nodes-cma-autoscaling-custom-adding
 #   - Name: Removing the Custom Metrics Autoscaler Operator
 #     File: nodes-cma-autoscaling-custom-removing
 # - Name: Controlling pod placement onto nodes (scheduling)

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

@@ -104,28 +104,29 @@ spec:
   fallback: <11>
     failureThreshold: 3
     replicas: 6
-  pollingInterval: 30 <12>
+    behavior: static <12>
+  pollingInterval: 30 <13>
   advanced:
-    restoreToOriginalReplicaCount: false <13>
+    restoreToOriginalReplicaCount: false <14>
     horizontalPodAutoscalerConfig:
-      name: keda-hpa-scale-down <14>
-      behavior: <15>
+      name: keda-hpa-scale-down <15>
+      behavior: <16>
         scaleDown:
           stabilizationWindowSeconds: 300
           policies:
           - type: Percent
             value: 100
             periodSeconds: 15
   triggers:
-  - type: prometheus <16>
+  - type: prometheus <17>
     metadata:
       serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
       namespace: kedatest
       metricName: http_requests_total
       threshold: '5'
       query: sum(rate(http_requests_total{job="test-app"}[1m]))
       authModes: basic
-    authenticationRef: <17>
+    authenticationRef: <18>
       name: prom-triggerauthentication
       kind: TriggerAuthentication
 ----
@@ -139,13 +140,18 @@ spec:
 <8> Optional: Specifies the maximum number of replicas when scaling up. The default is `100`.
 <9> Optional: Specifies the minimum number of replicas when scaling down.
 <10> Optional: Specifies the parameters for audit logs. as described in the "Configuring audit logging" section.
-<11> Optional: Specifies the number of replicas to fall back to if a scaler fails to get metrics from the source for the number of times defined by the `failureThreshold` parameter. For more information on fallback behavior, see the link:https://keda.sh/docs/2.7/concepts/scaling-deployments/#fallback[KEDA documentation].
-<12> Optional: Specifies the interval in seconds to check each trigger on. The default is `30`.
-<13> Optional: Specifies whether to scale back the target resource to the original replica count after the scaled object is deleted. The default is `false`, which keeps the replica count as it is when the scaled object is deleted.
-<14> Optional: Specifies a name for the horizontal pod autoscaler. The default is `keda-hpa-{scaled-object-name}`.
-<15> Optional: Specifies a scaling policy to use to control the rate to scale pods up or down, as described in the "Scaling policies" section.
-<16> Specifies the trigger to use as the basis for scaling, as described in the "Understanding the custom metrics autoscaler triggers" section. This example uses {product-title} monitoring.
-<17> Optional: Specifies a trigger authentication or a cluster trigger authentication. For more information, see _Understanding the custom metrics autoscaler trigger authentication_ in the _Additional resources_ section.
+<11> Optional: Specifies the number of replicas to fall back to if a scaler fails to get metrics from the source for the number of times defined by the `failureThreshold` parameter. For more information on fallback behavior, see the link:https://keda.sh/docs/latest/reference/scaledobject-spec/#fallback[KEDA documentation].
+<12> Optional: Specifies the replica count to be used if a fallback occurs. Enter one of the following options or omit the parameter:
+* Enter `static` to use the number of replicas specified by the `fallback.replicas` parameter. This is the default.
+* Enter `currentReplicas` to maintain the current number of replicas.
+* Enter `currentReplicasIfHigher` to maintain the current number of replicas, if that number is higher than the `fallback.replicas` parameter. If the current number of replicas is lower than the `fallback.replicas` parameter, use the `fallback.replicas` value.
+* Enter `currentReplicasIfLower` to maintain the current number of replicas, if that number is lower than the `fallback.replicas` parameter. If the current number of replicas is higher than the `fallback.replicas` parameter, use the `fallback.replicas` value.
+<13> Optional: Specifies the interval in seconds to check each trigger on. The default is `30`.
+<14> Optional: Specifies whether to scale back the target resource to the original replica count after the scaled object is deleted. The default is `false`, which keeps the replica count as it is when the scaled object is deleted.
+<15> Optional: Specifies a name for the horizontal pod autoscaler. The default is `keda-hpa-{scaled-object-name}`.
+<16> Optional: Specifies a scaling policy to use to control the rate to scale pods up or down, as described in the "Scaling policies" section.
+<17> Specifies the trigger to use as the basis for scaling, as described in the "Understanding the custom metrics autoscaler triggers" section. This example uses {product-title} monitoring.
+<18> Optional: Specifies a trigger authentication or a cluster trigger authentication. For more information, see _Understanding the custom metrics autoscaler trigger authentication_ in the _Additional resources_ section.
 * Enter `TriggerAuthentication` to use a trigger authentication. This is the default.
 * Enter `ClusterTriggerAuthentication` to use a cluster trigger authentication.
 

modules/nodes-cma-autoscaling-custom-prometheus-config.adoc

@@ -18,7 +18,6 @@ These steps are not required for an external Prometheus source.
 You must perform the following tasks, as described in this section:
 
 * Create a service account.
-* Create a secret that generates a token for the service account.
 * Create the trigger authentication.
 * Create a role.
 * Add that role to the service account.
@@ -45,7 +44,7 @@ $ oc project <project_name> <1>
 *  If you are using a trigger authentication, specify the project with the object you want to scale.
 *  If you are using a cluster trigger authentication, specify the `openshift-keda` project.
 
-. Create a service account and token, if your cluster does not have one:
+. Create a service account if your cluster does not have one:
 
 .. Create a `service account` object by using the following command:
 +
@@ -55,53 +54,6 @@ $ oc create serviceaccount thanos <1>
 ----
 <1> Specifies the name of the service account.
 
-.. Create a `secret` YAML to generate a service account token:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: Secret
-metadata:
-  name: thanos-token
-  annotations:
-    kubernetes.io/service-account.name: thanos <1>
-type: kubernetes.io/service-account-token
-----
-<1> Specifies the name of the service account.
-
-.. Create the secret object by using the following command:
-+
-[source,terminal]
-----
-$ oc create -f <file_name>.yaml
-----
-
-.. Use the following command to locate the token assigned to the service account:
-+
-[source,terminal]
-----
-$ oc describe serviceaccount thanos <1>
-----
-+
-<1> Specifies the name of the service account.
-+
---
-.Example output
-[source,terminal]
-----
-Name:                thanos
-Namespace:           <namespace_name>
-Labels:              <none>
-Annotations:         <none>
-Image pull secrets:  thanos-dockercfg-nnwgj
-Mountable secrets:   thanos-dockercfg-nnwgj
-Tokens:              thanos-token <1>
-Events:              <none>
-
-----
-<1> Use this token in the trigger authentication.
---
-
 . Create a trigger authentication with the service account token:
 
 .. Create a YAML file similar to the following:
@@ -113,23 +65,18 @@ kind: <authentication_method> <1>
 metadata:
   name: keda-trigger-auth-prometheus
 spec:
-  secretTargetRef: <2>
-  - parameter: bearerToken <3>
-    name: thanos-token <4>
-    key: token <5>
-  - parameter: ca
-    name: thanos-token
-    key: ca.crt
+  boundServiceAccountToken: <2>
+    - parameter: bearerToken <3>
+      serviceAccountName: thanos <4>
 ----
 <1> Specifies one of the following trigger authentication methods:
 +
 *  If you are using a trigger authentication, specify `TriggerAuthentication`. This example configures a trigger authentication.
 *  If you are using a cluster trigger authentication, specify `ClusterTriggerAuthentication`.
 +
-<2> Specifies that this object uses a secret for authorization.
-<3> Specifies the authentication parameter to supply by using the token.
-<4> Specifies the name of the token to use.
-<5> Specifies the key in the token to use with the specified parameter.
+<2> Specifies that this trigger authentication uses a bound service account token for authorization when connecting to the metrics endpoint.
+<3> Specifies the authentication parameter to supply by using the token. Here, the example uses bearer authentication.
+<4> Specifies the name of the service account to use.
 
 .. Create the CR object:
 +
@@ -221,3 +168,53 @@ You can now deploy a scaled object or scaled job to enable autoscaling for your
 * `triggers.metadata.authModes` must be `bearer`
 * `triggers.metadata.namespace` must be set to the namespace of the object to scale
 * `triggers.authenticationRef` must point to the trigger authentication resource specified in the previous step
+
+////
+Hiding, might not need it. If so, place this as step 2.
+.. Create a `secret` YAML to generate a service account token:
++
+[source,yaml]
+----
+apiVersion: v1
+kind: Secret
+metadata:
+  name: thanos-token
+  annotations:
+    kubernetes.io/service-account.name: thanos <1>
+type: kubernetes.io/service-account-token
+----
+<1> Specifies the name of the service account.
+
+.. Create the secret object by using the following command:
++
+[source,terminal]
+----
+$ oc create -f <file_name>.yaml
+----
+
+.. Use the following command to locate the token assigned to the service account:
++
+[source,terminal]
+----
+$ oc describe serviceaccount thanos <1>
+----
++
+<1> Specifies the name of the service account.
++
+--
+.Example output
+[source,terminal]
+----
+Name:                thanos
+Namespace:           <namespace_name>
+Labels:              <none>
+Annotations:         <none>
+Image pull secrets:  thanos-dockercfg-nnwgj
+Mountable secrets:   thanos-dockercfg-nnwgj
+Tokens:              thanos-token <1>
+Events:              <none>
+
+----
+<1> Use this token in the trigger authentication.
+--
+////

modules/nodes-cma-autoscaling-custom-trigger-auth-using.adoc

@@ -12,43 +12,69 @@ You use trigger authentications and cluster trigger authentications by using a c
 
 * The Custom Metrics Autoscaler Operator must be installed.
 
-* If you are using a secret, the `Secret` object must exist, for example:
+* If you are using a bound service account token, the service account must exist.
+
+* If you are using a bound service account token, a role-based access control (RBAC) object that enables the Custom Metrics Autoscaler Operator to request service account tokens from the service account must exist.
 +
-.Example secret
 [source,yaml]
 ----
-apiVersion: v1
-kind: Secret
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  name: keda-operator-token-creator
+  namespace: <namespace_name> <1>
+rules:
+- apiGroups:
+  - ""
+  resources:
+  - serviceaccounts/token
+  verbs:
+  - create
+  resourceNames:
+  - thanos <2>
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
 metadata:
-  name: my-secret
-data:
-  user-name: <base64_USER_NAME>
-  password: <base64_USER_PASSWORD>
+  name: keda-operator-token-creator-binding
+  namespace: <namespace_name> <3>
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: Role
+  name: keda-operator-token-creator
+subjects:
+- kind: ServiceAccount
+  name: keda-operator
+  namespace: openshift-keda
 ----
+<1> Specifies the namespace of the service account.
+<2> Specifies the name of the service account.
+<3> Specifies the namespace of the service account.
+
+* If you are using a secret, the `Secret` object must exist.
 
 .Procedure
 
 . Create the `TriggerAuthentication` or  `ClusterTriggerAuthentication` object.
 
 .. Create a YAML file that defines the object:
 +
-.Example trigger authentication with a secret
+.Example trigger authentication with a bound service account token
 [source,yaml]
 ----
 kind: TriggerAuthentication
 apiVersion: keda.sh/v1alpha1
 metadata:
   name: prom-triggerauthentication
-  namespace: my-namespace
-spec:
-  secretTargetRef:
-  - parameter: user-name
-    name: my-secret
-    key: USER_NAME
-  - parameter: password
-    name: my-secret
-    key: USER_PASSWORD
+  namespace: my-namespace <1>
+  spec:
+  boundServiceAccountToken: <2>
+    - parameter: token
+      serviceAccountName: thanos <3>
 ----
+<1> Specifies the namespace of the object you want to scale.
+<2> Specifies that this trigger authentication uses a bound service account token for authorization when connecting to the metrics endpoint.
+<3> Specifies the name of the service account to use.
 
 .. Create the `TriggerAuthentication` object:
 +

modules/nodes-cma-autoscaling-custom-trigger-prom.adoc

@@ -35,6 +35,7 @@ spec:
       cortexOrgID: my-org <8>
       ignoreNullValues: "false" <9>
       unsafeSsl: "false" <10>
+      timeout: 1000 <11>
 ----
 <1> Specifies Prometheus as the trigger type.
 <2> Specifies the address of the Prometheus server. This example uses  {product-title} monitoring.
@@ -51,7 +52,10 @@ spec:
      * If `false`, the certificate check is performed. This is the default behavior.
      * If `true`, the certificate check is not performed.
 +
+--
 [IMPORTANT]
 ====
 Skipping the check is not recommended.
 ====
+--
+<11> Optional: Specifies an HTTP request timeout in milliseconds for the HTTP client used by this Prometheus trigger. This value overrides any global timeout setting.