Fix: broken rendering in create new scaler markdown file

Signed-off-by: dttung2905 <[email protected]>

CREATE-NEW-SCALER.md

@@ -3,16 +3,16 @@
 ## Developing a scaler
 
 In order to develop a scaler, a developer should do the following:
-1. Download KEDA's code
+1. Download KEDA's code.
 2. Define the main pieces of data that you expect the user to supply so the scaler runs properly. For example, if your scaler needs to connect to an external source based on a connection string, you expect the user to supply this connection string in the configuration within the ScaledObject under `trigger`. This data will be passed to your constructing function as map[string]string.
-2. Create the new scaler struct under the `pkg/scalers` folder.
-3. Implement the methods defined in the [scaler interface](#scaler-interface) section.
-4. Create a constructor according to [this](#constructor).
-5. Change the `buildScaler` function in `pkg/scaling/scalers_builder.go` by adding another switch case that matches your scaler. Scalers in the switch are ordered alphabetically, please follow the same pattern.
-6. Run `make build` from the root of KEDA and your scaler is ready.
-
-If you want to deploy locally
-1. Open the terminal and go to the root of the source code
+3. Create the new scaler struct under the `pkg/scalers` folder.
+4. Implement the methods defined in the [scaler interface](#scaler-interface) section.
+5. Create a constructor according to [this](#constructor).
+6. Change the `buildScaler` function in `pkg/scaling/scalers_builder.go` by adding another switch case that matches your scaler. Scalers in the switch are ordered alphabetically, please follow the same pattern.
+7. Run `make build` from the root of KEDA and your scaler is ready.
+
+If you want to deploy locally:
+1. Open the terminal and go to the root of the source code.
 2. Run `IMAGE_REGISTRY=docker.io IMAGE_REPO=johndoe make publish`, where `johndoe` is your Docker Hub repo, this will create and publish images with your build of KEDA into your repo. Please refer [the guide for local deployment](https://github.com/kedacore/keda/blob/main/BUILD.md#custom-keda-locally-outside-cluster) for more details.
 3. Run `IMAGE_REGISTRY=docker.io IMAGE_REPO=johndoe make deploy`, this will deploy KEDA to your cluster.
 
@@ -40,7 +40,7 @@ Kubernetes HPA (Horizontal Pod Autoscaler) will poll `GetMetricsAndActivity` reg
 For more details check [Kubernetes HPA documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).
 
 <br>Next lines are an example about how to use it:
->```golang
+```golang
 func (s *artemisScaler) GetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error) {
 	messages, err := s.getQueueMessageCount(ctx)
 
@@ -53,7 +53,7 @@ func (s *artemisScaler) GetMetricsAndActivity(ctx context.Context, metricName st
 
 	return []external_metrics.ExternalMetricValue{metric}, messages > s.metadata.activationQueueLength, nil
 }
->```
+```
 
 
 ### GetMetricSpecForScaling
@@ -63,7 +63,7 @@ KEDA works in conjunction with Kubernetes Horizontal Pod Autoscaler (HPA). When
 The return type of this function is `MetricSpec`, but in KEDA's case we will mostly write External metrics. So the property that should be filled is `ExternalMetricSource`, where the:
 - `MetricName`: the name of our metric we are returning in this scaler. The name should be unique, to allow setting multiple (even the same type) Triggers in one ScaledObject, but each function call should return the same name.
 - `TargetValue`: is the value of the metric we want to reach at all times at all costs. As long as the current metric doesn't match TargetValue, HPA will increase the number of the pods until it reaches the maximum number of pods allowed to scale to.
-- `TargetAverageValue`: the value of the metric for which we require one pod to handle. e.g. if we are have a scaler based on the length of a message queue, and we specificy 10 for `TargetAverageValue`, we are saying that each pod will handle 10 messages. So if the length of the queue becomes 30, we expect that we have 3 pods in our cluster. (`TargetAverage` and `TargetValue` are mutually exclusive)
+- `TargetAverageValue`: the value of the metric for which we require one pod to handle. e.g. if we have a scaler based on the length of a message queue, and we specificy 10 for `TargetAverageValue`, we are saying that each pod will handle 10 messages. So if the length of the queue becomes 30, we expect that we have 3 pods in our cluster. (`TargetAverage` and `TargetValue` are mutually exclusive).
 
 All scalers receive a parameter named `scalerIndex` as part of `ScalerConfig`. This value is the index of the current scaler in a ScaledObject. All metric names have to start with `sX-` (where `X` is `scalerIndex`). This convention makes the metric name unique in the ScaledObject and brings the option to have more than 1 "similar metric name" defined in a ScaledObject.
 
@@ -104,10 +104,10 @@ The constructor should have the following parameters:
 
 ## Lifecycle of a scaler
 
-Scalers are created and cached until the ScaledObject is modified, or `.IsActive()`/`GetMetrics()` result in an error. The cached scaler is then invalidated and a new scaler is created. `Close()` is called on all scalers when disposed.
+Scalers are created and cached until the ScaledObject is modified, or `GetMetricsAndActivity()` result in an error. The cached scaler is then invalidated and a new scaler is created. `Close()` is called on all scalers when disposed.
 
 ## Note
 The scaler code is embedded into the two separate binaries comprising KEDA, the operator and the custom metrics server component. The metrics server must be occasionally rebuilt published and deployed to k8s for it to have the same code as your operator.
 
 GetMetricSpecForScaling() is executed by the operator for the purposes of scaling out and in to 0 replicas.
-GetMetrics() is executed by the custom metrics server in response to a calls against the external metrics api, whether by the HPA loop or by curl
+GetMetricsAndActivity() is executed by the KEDA Metrics server in response to a calls against the external metrics api, whether by the HPA loop or by curl.