Update docs for Function Mesh v0.1.7 release

docs/connectors/io-crd-config/sink-crd-config.md

@@ -14,9 +14,10 @@ This table lists sink configurations.
 | `name` | The name of a sink connector. |
 | `classname` | The class name of a sink connector. |
 | `tenant` | The tenant of a sink connector. |
+| `namespace` | The Pulsar namespace of a sink connector. |
 | `Replicas`| The number of instances that you want to run this sink connector. By default, the `Replicas` is set to `1`. |
 | `MaxReplicas`| The maximum number of Pulsar instances that you want to run for this sink connector. When the value of the `maxReplicas` parameter is greater than the value of `replicas`, it indicates that the sink controller automatically scales the sink connector based on the CPU usage. By default, `maxReplicas` is set to 0, which indicates that auto-scaling is disabled. |
-| `SinkConfig` | The map to a ConfigMap specifying the configuration of a sink connector. |
+| `SinkConfig` | The sink connector configurations in YAML format.|
 | `Timeout` | The message timeout in milliseconds. |
 | `NegativeAckRedeliveryDelayMs`| The number of redelivered messages due to negative acknowledgement. |
 | `AutoAck` | Whether or not the framework acknowledges messages automatically. This field is required. You can set it to `true` or `false`.|
@@ -122,3 +123,6 @@ Function Mesh supports customizing the Pod running Pulsar connectors. This table
 | `ServiceAccountName` | Specify the name of the service account which is used to run Pulsar Functions or connectors in the Function Mesh Worker service.|
 | `InitContainers` | The initialization containers belonging to a Pod. A typical use case could be using an initialization container to download a remote JAR to a local path. |
 | `Sidecars` | Sidecar containers run together with the main function container in a Pod. |
+| `BuiltinAutoscaler` | Specify the built-in autoscaling rules. <br /> - CPU-based autoscaling: auto-scale the number of Pods based on the CPU usage (80%, 50%, or 20%). <br />- Memory-based autoscaling: auto-scale the number of Pods based on the memory usage (80%, 50%, or 20%). <br /> If you configure the `BuiltinAutoscaler` field, you do not need to configure the `AutoScalingMetrics` and `AutoScalingBehavior` options and vice versa.|
+| `AutoScalingMetrics` | Specify how to scale based on customized metrics defined in connectors. For details, see [MetricSpec v2beta2 autoscaling](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#metricspec-v2beta2-autoscaling). |
+| `AutoScalingBehavior` | Configure the scaling behavior of the target in both up and down directions (`scaleUp` and `scaleDown` fields respectively). If not specified, the default Kubernetes scaling behaviors are adopted. For details, see [HorizontalPodAutoscalerBehavior v2beta2 autoscaling](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#horizontalpodautoscalerbehavior-v2beta2-autoscaling). |

docs/connectors/io-crd-config/source-crd-config.md

@@ -14,10 +14,12 @@ This table lists source configurations.
 | `name` | The name of a source connector. |
 | `classname` | The class name of a source connector. |
 | `tenant` | The tenant of a source connector. |
+| `namespace` | The Pulsar namespace of a source connector. |
 | `Replicas`| The number of instances that you want to run this source connector. |
 | `MaxReplicas`| The maximum number of Pulsar instances that you want to run for this source connector. When the value of the `maxReplicas` parameter is greater than the value of `replicas`, it indicates that the source controller automatically scales the source connector based on the CPU usage. By default, `maxReplicas` is set to 0, which indicates that auto-scaling is disabled. |
-| `SourceConfig` | The map to a ConfigMap specifying the configuration of a source connector. |
+| `SourceConfig` | The source connector configurations in YAML format. |
 | `ProcessingGuarantee` | The processing guarantees (delivery semantics) applied to the source connector. Available values: `ATLEAST_ONCE`, `ATMOST_ONCE`, `EFFECTIVELY_ONCE`.|
+| `ForwardSourceMessageProperty` | Configure whether to pass message properties to a target topic. |
 
 ## Images
 
@@ -114,3 +116,6 @@ Function Mesh supports customizing the Pod running connectors. This table lists
 | `ServiceAccountName` | Specify the name of the service account which is used to run Pulsar Functions or connectors in the Function Mesh Worker service.|
 | `InitContainers` | Initialization containers belonging to a Pod. A typical use case could be using an Initialization container to download a remote JAR to a local path. |
 | `Sidecars` | Sidecar containers run together with the main function container in a Pod. |
+| `BuiltinAutoscaler` | Specify the built-in autoscaling rules. <br /> - CPU-based autoscaling: auto-scale the number of Pods based on the CPU usage (80%, 50%, or 20%). <br />- Memory-based autoscaling: auto-scale the number of Pods based on the memory usage (80%, 50%, or 20%). <br /> If you configure the `BuiltinAutoscaler` field, you do not need to configure the `AutoScalingMetrics` and `AutoScalingBehavior` options and vice versa.|
+| `AutoScalingMetrics` | Specify how to scale based on customized metrics defined in connectors. For details, see [MetricSpec v2beta2 autoscaling](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#metricspec-v2beta2-autoscaling). |
+| `AutoScalingBehavior` | Configure the scaling behavior of the target in both up and down directions (`scaleUp` and `scaleDown` fields respectively). If not specified, the default Kubernetes scaling behaviors are adopted. For details, see [HorizontalPodAutoscalerBehavior v2beta2 autoscaling](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#horizontalpodautoscalerbehavior-v2beta2-autoscaling). |

docs/connectors/pulsar-io-debug.md

@@ -18,7 +18,7 @@ In addition, you can use the following command to check the specific Pod.
 
 - `kubectl describe pod POD_NAME -n NAMESPACE_NAME`: check the current state of the Pod and recent events.
 
-For the use of `kubectl` commands, see [here](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands).
+For the use of `kubectl` commands, see [kubectl command reference](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands).
 
 ## Use log topics
 

docs/connectors/run-connector.md

@@ -148,6 +148,10 @@ This section describes how to package a Pulsar connector to a NAR or JAR package
 
 Use the `pulsar-admin` CLI tool to upload the NAR or uber JAR package to the [Pulsar package management service](http://pulsar.apache.org/docs/en/next/admin-api-packages/).
 
+> **Note**
+> 
+> Before uploading the package to Pulsar package management service, you need to enable the package management service in the `broker.config` file.
+
 This example shows how to upload the NAR package of the `my-sink` connector to the [Pulsar package management service](http://pulsar.apache.org/docs/en/next/admin-api-packages/).
 
 ```bash

docs/functions/function-crd.md

@@ -15,16 +15,17 @@ This table lists Pulsar Function configurations.
 | `name` | The name of a Pulsar Function. |
 | `classname` | The class name of a Pulsar Function. |
 | `tenant` | The tenant of a Pulsar Function. |
-| `namespace` | The namespace of a Pulsar Function. |
+| `namespace` | The Pulsar namespace of a Pulsar Function. |
 | `Replicas`| The number of instances that you want to run this Pulsar Function. By default, the `Replicas` is set to `1`. |
 | `MaxReplicas`| The maximum number of Pulsar instances that you want to run for this Pulsar Function. When the value of the `maxReplicas` parameter is greater than the value of `replicas`, it indicates that the Functions controller automatically scales the Pulsar Functions based on the CPU usage. By default, `maxReplicas` is set to 0, which indicates that auto-scaling is disabled. |
 | `Timeout` | The message timeout in milliseconds. |
 | `DeadLetterTopic` | The topic where all messages that were not processed successfully are sent. This parameter is not supported in Python Functions. |
-| `FuncConfig` | The map to a ConfigMap specifying the configuration of a Pulsar function. |
+| `FuncConfig` | Pulsar Functions configurations in YAML format. |
 | `LogTopic` | The topic to which the logs of a Pulsar Function are produced. |
 | `AutoAck` | Whether or not the framework acknowledges messages automatically. This field is required. You can set it to `true` or `false`.|
 | `MaxMessageRetry` | How many times to process a message before giving up. |
 | `ProcessingGuarantee` | The processing guarantees (delivery semantics) applied to the function. Available values: `ATLEAST_ONCE`, `ATMOST_ONCE`, `EFFECTIVELY_ONCE`.|
+| `ForwardSourceMessageProperty` | Configure whether to pass message properties to a target topic. |
 | `RetainOrdering` | Function consumes and processes messages in order. |
 | `RetainKeyOrdering`| Configure whether to retain the key order of messages. |
 | `SubscriptionName` | Pulsar Functions’ subscription name if you want a specific subscription-name for the input-topic consumer. |
@@ -147,3 +148,6 @@ Function Mesh supports customizing the Pod running function instance. This table
 | `ServiceAccountName` | Specify the name of the service account which is used to run Pulsar Functions or connectors in the Function Mesh Worker service.|
 | `InitContainers` | Initialization containers belonging to a Pod. A typical use case could be using an Initialization container to download a remote JAR to a local path. |
 | `Sidecars` | Sidecar containers run together with the main function container in a Pod. |
+| `BuiltinAutoscaler` | Specify the built-in autoscaling rules. <br /> - CPU-based autoscaling: auto-scale the number of Pods based on the CPU usage (80%, 50%, or 20%). <br />- Memory-based autoscaling: auto-scale the number of Pods based on the memory usage (80%, 50%, or 20%). <br /> If you configure the `BuiltinAutoscaler` field, you do not need to configure the `AutoScalingMetrics` and `AutoScalingBehavior` options and vice versa.|
+| `AutoScalingMetrics` | Specify how to scale based on customized metrics defined in Pulsar Functions. For details, see [MetricSpec v2beta2 autoscaling](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#metricspec-v2beta2-autoscaling). |
+| `AutoScalingBehavior` | Configure the scaling behavior of the target in both up and down directions (`scaleUp` and `scaleDown` fields respectively). If not specified, the default Kubernetes scaling behaviors are adopted. For details, see [HorizontalPodAutoscalerBehavior v2beta2 autoscaling](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#horizontalpodautoscalerbehavior-v2beta2-autoscaling). |

docs/functions/function-debug.md

@@ -18,7 +18,7 @@ In addition, you can use the following command to check the specific Pod.
 
 - `kubectl describe pod POD_NAME -n NAMESPACE_NAME`: check the current state of the Pod and recent events.
 
-For the use of `kubectl` commands, see [here](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands).
+For the use of `kubectl` commands, see [kubectl command reference](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands).
 
 ## Use log topic
 

docs/functions/run-function/run-go-function.md

@@ -86,6 +86,10 @@ To package Go Functions in Go, follow these steps.
 
 Use the `pulsar-admin` CLI tool to upload the package to the [Pulsar package management service](http://pulsar.apache.org/docs/en/next/admin-api-packages/).
 
+> **Note**
+> 
+> Before uploading the package to Pulsar package management service, you need to enable the package management service in the `broker.config` file.
+
 This example shows how to upload the package of the `my-function@0.1` Functions to the [Pulsar package management service](http://pulsar.apache.org/docs/en/next/admin-api-packages/).
 
 ```bash

docs/functions/run-function/run-java-function.md

@@ -116,6 +116,10 @@ To package a Functions in Java, follow these steps.
 
 Use the `pulsar-admin` CLI tool to upload the package to the [Pulsar package management service](http://pulsar.apache.org/docs/en/next/admin-api-packages/).
 
+> **Note**
+> 
+> Before uploading the package to Pulsar package management service, you need to enable the package management service in the `broker.config` file.
+
 This example shows how to upload the package of the `my-function@0.1` Functions to the [Pulsar package management service](http://pulsar.apache.org/docs/en/next/admin-api-packages/).
 
 ```bash

docs/functions/run-function/run-python-function.md

@@ -79,6 +79,10 @@ Python Function supports One Python file or ZIP file.
 
 Use the `pulsar-admin` CLI tool to upload the package to the [Pulsar package management service](http://pulsar.apache.org/docs/en/next/admin-api-packages/).
 
+> **Note**
+> 
+> Before uploading the package to Pulsar package management service, you need to enable the package management service in the `broker.config` file.
+
 This example shows how to upload the package of the `my-function@0.1` Functions to the [Pulsar package management service](http://pulsar.apache.org/docs/en/next/admin-api-packages/).
 
 ```bash

docs/install-function-mesh.md

@@ -41,7 +41,7 @@ This example shows how to install Function Mesh through [Helm](https://helm.sh/)
 > **Note**
 >
 > - Before installation, ensure that Helm v3 is installed properly.
-> - For the use of `kubectl` commands, see [here](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands).
+> - For the use of `kubectl` commands, see [kubectl command reference](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands).
 
 1. Clone the StreamNative Function Mesh repository.