pulsar-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sanjee...@apache.org
Subject [incubator-pulsar] branch master updated: Updated documentation about changed arguments for functions, sources and sinks (#2457)
Date Thu, 30 Aug 2018 02:34:33 GMT
This is an automated email from the ASF dual-hosted git repository.

sanjeevrk pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-pulsar.git


The following commit(s) were added to refs/heads/master by this push:
     new 87fb48f  Updated documentation about changed arguments for functions, sources and sinks (#2457)
87fb48f is described below

commit 87fb48feaa1c2dfe31f08833a8a9f889837f6d96
Author: Sanjeev Kulkarni <sanjeevrk@gmail.com>
AuthorDate: Wed Aug 29 19:34:30 2018 -0700

    Updated documentation about changed arguments for functions, sources and sinks (#2457)
    
    * Updated documentation about changed arguments for functions, sources and sinks
    
    * Some missing files
---
 .../org/apache/pulsar/admin/cli/CmdFunctions.java  |   2 +-
 .../java/org/apache/pulsar/admin/cli/CmdSinks.java |   4 -
 site2/docs/deploy-bare-metal.md                    |   4 +-
 site2/docs/functions-api.md                        |  73 +++---
 site2/docs/functions-deploying.md                  |  20 +-
 site2/docs/functions-guarantees.md                 |   4 +-
 site2/docs/functions-overview.md                   |  24 +-
 site2/docs/functions-quickstart.md                 |  10 +-
 site2/docs/io-managing.md                          |  20 +-
 site2/docs/io-quickstart.md                        |   2 +-
 site2/docs/reference-pulsar-admin.md               | 272 ++++++++++++++++-----
 11 files changed, 295 insertions(+), 140 deletions(-)

diff --git a/pulsar-client-tools/src/main/java/org/apache/pulsar/admin/cli/CmdFunctions.java b/pulsar-client-tools/src/main/java/org/apache/pulsar/admin/cli/CmdFunctions.java
index 88412a6..18d483c 100644
--- a/pulsar-client-tools/src/main/java/org/apache/pulsar/admin/cli/CmdFunctions.java
+++ b/pulsar-client-tools/src/main/java/org/apache/pulsar/admin/cli/CmdFunctions.java
@@ -770,7 +770,7 @@ public class CmdFunctions extends CmdBase {
         // for backwards compatibility purposes
         @Parameter(names = "--stateStorageServiceUrl", description = "The URL for the state storage service (by default Apache BookKeeper)", hidden = true)
         protected String DEPRECATED_stateStorageServiceUrl;
-        @Parameter(names = "--state-storag-service-url", description = "The URL for the state storage service (by default Apache BookKeeper)")
+        @Parameter(names = "--state-storage-service-url", description = "The URL for the state storage service (by default Apache BookKeeper)")
         protected String stateStorageServiceUrl;
         // for backwards compatibility purposes
         @Parameter(names = "--brokerServiceUrl", description = "The URL for the Pulsar broker", hidden = true)
diff --git a/pulsar-client-tools/src/main/java/org/apache/pulsar/admin/cli/CmdSinks.java b/pulsar-client-tools/src/main/java/org/apache/pulsar/admin/cli/CmdSinks.java
index 5259996..3e49600 100644
--- a/pulsar-client-tools/src/main/java/org/apache/pulsar/admin/cli/CmdSinks.java
+++ b/pulsar-client-tools/src/main/java/org/apache/pulsar/admin/cli/CmdSinks.java
@@ -244,10 +244,6 @@ public class CmdSinks extends CmdBase {
         @Parameter(names = "--topics-pattern", description = "TopicsPattern to consume from list of topics under a namespace that match the pattern. [--input] and [--topicsPattern] are mutually exclusive. Add SerDe class name for a pattern in --customSerdeInputs  (supported for java fun only)")
         protected String topicsPattern;
 
-        @Parameter(names = { "-st",
-                "--schema-type" }, description = "The builtin schema type (eg: 'avro', 'json', etc..) or the class name for a Schema implementation")
-        protected String schemaType = "";
-
         @Parameter(names = "--subsName", description = "Pulsar source subscription name if user wants a specific subscription-name for input-topic consumer", hidden = true)
         protected String DEPRECATED_subsName;
         @Parameter(names = "--subs-name", description = "Pulsar source subscription name if user wants a specific subscription-name for input-topic consumer")
diff --git a/site2/docs/deploy-bare-metal.md b/site2/docs/deploy-bare-metal.md
index b0590a0..a65a45a 100644
--- a/site2/docs/deploy-bare-metal.md
+++ b/site2/docs/deploy-bare-metal.md
@@ -334,7 +334,7 @@ Create a ExclamationFunction `exclamation`.
 ```bash
 bin/pulsar-admin functions create \
   --jar examples/api-examples.jar \
-  --className org.apache.pulsar.functions.api.examples.ExclamationFunction \
+  --classname org.apache.pulsar.functions.api.examples.ExclamationFunction \
   --inputs persistent://public/default/exclamation-input \
   --output persistent://public/default/exclamation-output \
   --tenant public \
@@ -345,7 +345,7 @@ bin/pulsar-admin functions create \
 Check if the function is running as expected by [triggering](functions-deploying.md#triggering-pulsar-functions) the function.
 
 ```bash
-bin/pulsar-admin functions trigger --name exclamation --triggerValue "hello world"
+bin/pulsar-admin functions trigger --name exclamation --trigger-value "hello world"
 ```
 
 You will see output as below:
diff --git a/site2/docs/functions-api.md b/site2/docs/functions-api.md
index a52128c..283fcd4 100644
--- a/site2/docs/functions-api.md
+++ b/site2/docs/functions-api.md
@@ -47,13 +47,13 @@ Deploying Pulsar Functions is handled by the [`pulsar-admin`](reference-pulsar-a
 ```bash
 $ bin/pulsar-admin functions localrun \
   --py sanitizer.py \          # The Python file with the function's code
-  --className sanitizer \      # The class or function holding the processing logic
+  --classname sanitizer \      # The class or function holding the processing logic
   --tenant public \            # The function's tenant (derived from the topic name by default)
   --namespace default \        # The function's namespace (derived from the topic name by default)
   --name sanitizer-function \  # The name of the function (the class name by default)
   --inputs dirty-strings-in \  # The input topic(s) for the function
   --output clean-strings-out \ # The output topic for the function
-  --logTopic sanitizer-logs    # The topic to which all functions logs are published
+  --log-topic sanitizer-logs   # The topic to which all functions logs are published
 ```
 
 For instructions on running functions in your Pulsar cluster, see the [Deploying Pulsar Functions](functions-deploying.md) guide.
@@ -85,7 +85,16 @@ class DisplayFunctionName(Function):
         return "The function processing this message has the name {0}".format(function_name)
 ```
 
-### Serialization and deserialization (SerDe)
+### Functions, Messages and Message Types
+
+Pulsar Functions can take byte arrays as inputs and spit out byte arrays as output. However in languages that support typed interfaces(just Java at the moment) one can write typed Functions as well. In this scenario, there are two ways one can bind messages to types.
+* [Schema Registry](#Schema-Registry)
+* [SerDe](#SerDe)
+
+### Schema Registry
+Pulsar has a built in [Schema Registry](concepts-schema-registry) and comes bundled with a variety of popular schema types(avro, json and protobuf). Pulsar Functions can leverage existing schema information from input topics to derive the input type. The same applies for output topic as well.
+
+### SerDe
 
 SerDe stands for **Ser**ialization and **De**serialization. All Pulsar Functions use SerDe for message handling. How SerDe works by default depends on the language you're using for a particular function:
 
@@ -119,7 +128,7 @@ When you run or update Pulsar Functions created using the [SDK](#available-apis)
 $ bin/pulsar-admin functions create \
   --name word-filter \
   # Other function configs
-  --userConfig '{"forbidden-word":"rosebud"}'
+  --user-config '{"forbidden-word":"rosebud"}'
 ```
 
 If the function were a Python function, that config value could be accessed like this:
@@ -242,11 +251,10 @@ The {@inject: javadoc:Context:/client/org/apache/pulsar/functions/api/Context} i
 
 ```java
 public interface Context {
-    byte[] getMessageId();
-    String getTopicName();
-    Collection<String> getSourceTopics();
-    String getSinkTopic();
-    String getOutputSerdeClassName();
+    Record<?> getCurrentRecord();
+    Collection<String> getInputTopics();
+    String getOutputTopic();
+    String getOutputSchemaType();
     String getTenant();
     String getNamespace();
     String getFunctionName();
@@ -254,13 +262,16 @@ public interface Context {
     String getInstanceId();
     String getFunctionVersion();
     Logger getLogger();
-    Map<String, String> getUserConfigMap();
-    Optional<String> getUserConfigValue(String key);
-    String getUserConfigValueOrDefault(String key, String default);
+    void incrCounter(String key, long amount);
+    long getCounter(String key);
+    void putState(String key, ByteBuffer value);
+    ByteBuffer getState(String key);
+    Map<String, Object> getUserConfigMap();
+    Optional<Object> getUserConfigValue(String key);
+    Object getUserConfigValueOrDefault(String key, Object defaultValue);
     void recordMetric(String metricName, double value);
-    <O> CompletableFuture<Void> publish(String topicName, O object, String serDeClassName);
+    <O> CompletableFuture<Void> publish(String topicName, O object, String schemaOrSerdeClassName);
     <O> CompletableFuture<Void> publish(String topicName, O object);
-    CompletableFuture<Void> ack(byte[] messageId, String topic);
 }
 ```
 
@@ -382,7 +393,7 @@ Here's an example [`create`](reference-pulsar-admin.md#create-1) operation:
 ```bash
 $ bin/pulsar-admin functions create \
   --jar /path/to/your.jar \
-  --outputSerdeClassName com.example.serde.TweetSerde \
+  --output-serde-classname com.example.serde.TweetSerde \
   # Other function attributes
 ```
 
@@ -420,8 +431,8 @@ If you want your function to produce logs, you need to specify a log topic when
 ```bash
 $ bin/pulsar-admin functions create \
   --jar my-functions.jar \
-  --className my.package.LoggingFunction \
-  --logTopic persistent://public/default/logging-function-logs \
+  --classname my.package.LoggingFunction \
+  --log-topic persistent://public/default/logging-function-logs \
   # Other function configs
 ```
 
@@ -434,7 +445,7 @@ The Java SDK's [`Context`](#context) object enables you to access key/value pair
 ```bash
 $ bin/pulsar-admin functions create \
   # Other function configs
-  --userConfig '{"word-of-the-day":"verdure"}'
+  --user-config '{"word-of-the-day":"verdure"}'
 ```
 
 To access that value in a Java function:
@@ -511,18 +522,12 @@ Writing Pulsar Functions in Python entails implementing one of two things:
 
 ### Getting started
 
-Regardless of which [deployment mode](functions-deploying.md) you're using, you'll need to install the following Python libraries on any machine that's running Pulsar Functions written in Python:
-
-* pulsar-client
-* protobuf
-* futures
-* grpcio
-* grpcio-tools
+Regardless of which [deployment mode](functions-deploying.md) you're using, 'pulsar-client' python library has to installed on any machine that's running Pulsar Functions written in Python.
 
 That could be your local machine for [local run mode](functions-deploying.md#local-run-mode) or a machine running a Pulsar [broker](reference-terminology.md#broker) for [cluster mode](functions-deploying.md#cluster-mode). To install those libraries using pip:
 
 ```bash
-$ pip install pulsar-client protobuf futures grpcio grpcio-tools
+$ pip install pulsar-client
 ```
 
 ### Packaging
@@ -567,7 +572,9 @@ The [`Context`](https://github.com/apache/incubator-pulsar/blob/master/pulsar-cl
 Method | What it provides
 :------|:----------------
 `get_message_id` | The message ID of the message being processed
-`get_topic_name` | The input topic of the message being processed
+`get_current_message_topic_name` | The topic of the message being currently being processed
+`get_function_tenant` | The tenant under which the current Pulsar Function runs under
+`get_function_namespace` | The namespace under which the current Pulsar Function runs under
 `get_function_name` | The name of the current Pulsar Function
 `get_function_id` | The ID of the current Pulsar Function
 `get_instance_id` | The ID of the current Pulsar Functions instance
@@ -590,9 +597,9 @@ $ bin/pulsar-admin functions create \
   --namespace default \
   --name my_function \
   --py my_function.py \
-  --className my_function.MyFunction \
-  --customSerdeInputs '{"input-topic-1":"Serde1","input-topic-2":"Serde2"}' \
-  --outputSerdeClassName Serde3 \
+  --classname my_function.MyFunction \
+  --custom-serde-inputs '{"input-topic-1":"Serde1","input-topic-2":"Serde2"}' \
+  --output-serde-classname Serde3 \
   --output output-topic-1
 ```
 
@@ -665,8 +672,8 @@ If you want your function to produce logs on a Pulsar topic, you need to specify
 ```bash
 $ bin/pulsar-admin functions create \
   --py logging_function.py \
-  --className logging_function.LoggingFunction \
-  --logTopic logging-function-logs \
+  --classname logging_function.LoggingFunction \
+  --log-topic logging-function-logs \
   # Other function configs
 ```
 
@@ -679,7 +686,7 @@ The Python SDK's [`Context`](#context) object enables you to access key/value pa
 ```bash
 $ bin/pulsar-admin functions create \
   # Other function configs \
-  --userConfig '{"word-of-the-day":"verdure"}'
+  --user-config '{"word-of-the-day":"verdure"}'
 ```
 
 To access that value in a Python function:
diff --git a/site2/docs/functions-deploying.md b/site2/docs/functions-deploying.md
index dcf2d3b..27f214c 100644
--- a/site2/docs/functions-deploying.md
+++ b/site2/docs/functions-deploying.md
@@ -43,7 +43,7 @@ When managing Pulsar Functions, you'll need to specify a variety of information
 
 Parameter | Default
 :---------|:-------
-Function name | Whichever value is specified for the class name (minus org, library, etc.). The flag `--className org.example.MyFunction`, for example, would give the function a name of `MyFunction`.
+Function name | Whichever value is specified for the class name (minus org, library, etc.). The flag `--classname org.example.MyFunction`, for example, would give the function a name of `MyFunction`.
 Tenant | Derived from the input topics' names. If the input topics are under the `marketing` tenant---i.e. the topic names have the form `persistent://marketing/{namespace}/{topicName}`---then the tenant will be `marketing`.
 Namespace | Derived from the input topics' names. If the input topics are under the `asia` namespace under the `marketing` tenant---i.e. the topic names have the form `persistent://marketing/asia/{topicName}`, then the namespace will be `asia`.
 Output topic | `{input topic}-{function name}-output`. A function with an input topic name of `incoming` and a function name of `exclamation`, for example, would have an output topic of `incoming-exclamation-output`.
@@ -58,7 +58,7 @@ Take this `create` command:
 ```bash
 $ bin/pulsar-admin functions create \
   --jar my-pulsar-functions.jar \
-  --className org.example.MyFunction \
+  --classname org.example.MyFunction \
   --inputs my-function-input-topic1,my-function-input-topic2
 ```
 
@@ -71,7 +71,7 @@ If you run a Pulsar Function in **local run** mode, it will run on the machine f
 ```bash
 $ bin/pulsar-admin functions localrun \
   --py myfunc.py \
-  --className myfunc.SomeFunction \
+  --classname myfunc.SomeFunction \
   --inputs persistent://public/default/input-1 \
   --output persistent://public/default/output-1
 ```
@@ -80,7 +80,7 @@ By default, the function will connect to a Pulsar cluster running on the same ma
 
 ```bash
 $ bin/pulsar-admin functions localrun \
-  --brokerServiceUrl pulsar://my-cluster-host:6650 \
+  --broker-service-url pulsar://my-cluster-host:6650 \
   # Other function parameters
 ```
 
@@ -91,7 +91,7 @@ When you run a Pulsar Function in **cluster mode**, the function code will be up
 ```bash
 $ bin/pulsar-admin functions create \
   --py myfunc.py \
-  --className myfunc.SomeFunction \
+  --classname myfunc.SomeFunction \
   --inputs persistent://public/default/input-1 \
   --output persistent://public/default/output-1
 ```
@@ -103,7 +103,7 @@ You can use the [`update`](reference-pulsar-admin.md#update-1) command to update
 ```bash
 $ bin/pulsar-admin functions update \
   --py myfunc.py \
-  --className myfunc.SomeFunction \
+  --classname myfunc.SomeFunction \
   --inputs persistent://public/default/new-input-topic \
   --output persistent://public/default/new-output-topic
 ```
@@ -143,7 +143,7 @@ And here's the corresponding update command:
 
 ```bash
 $ bin/pulsar-admin functions update \
-  --functionConfigFile function-config.yaml
+  --function-config-file function-config.yaml
 ```
 
 ### Function instance resources
@@ -161,7 +161,7 @@ Here's an example function creation command that allocates 8 cores, 8 GB of RAM,
 ```bash
 $ bin/pulsar-admin functions create \
   --jar target/my-functions.jar \
-  --className org.example.functions.MyFunction \
+  --classname org.example.functions.MyFunction \
   --cpu 8 \
   --ram 8589934592 \
   --disk 10737418240
@@ -192,7 +192,7 @@ $ bin/pulsar-admin functions create \
   --namespace default \
   --name myfunc \
   --py myfunc.py \
-  --className myfunc \
+  --classname myfunc \
   --inputs persistent://public/default/in \
   --output persistent://public/default/out
 ```
@@ -212,7 +212,7 @@ $ bin/pulsar-admin functions trigger \
   --tenant public \
   --namespace default \
   --name myfunc \
-  --triggerValue "hello world"
+  --trigger-value "hello world"
 ```
 
 The consumer listening on the output topic should then produce this in its logs:
diff --git a/site2/docs/functions-guarantees.md b/site2/docs/functions-guarantees.md
index 1c731eb..738439f 100644
--- a/site2/docs/functions-guarantees.md
+++ b/site2/docs/functions-guarantees.md
@@ -18,7 +18,7 @@ You can set the processing guarantees for a Pulsar Function when you create the
 
 ```bash
 $ bin/pulsar-admin functions create \
-  --processingGuarantees EFFECTIVELY_ONCE \
+  --processing-guarantees EFFECTIVELY_ONCE \
   # Other function configs
 ```
 
@@ -36,6 +36,6 @@ You can change the processing guarantees applied to a function once it's already
 
 ```bash
 $ bin/pulsar-admin functions update \
-  --processingGuarantees ATMOST_ONCE \
+  --processing-guarantees ATMOST_ONCE \
   # Other function configs
 ```
diff --git a/site2/docs/functions-overview.md b/site2/docs/functions-overview.md
index 2bc1e36..2a5f81d 100644
--- a/site2/docs/functions-overview.md
+++ b/site2/docs/functions-overview.md
@@ -97,7 +97,7 @@ public class WordCountFunction implements Function<String, Void> {
 ```bash
 $ bin/pulsar-admin functions create \
   --jar target/my-jar-with-dependencies.jar \
-  --className org.example.functions.WordCountFunction \
+  --classname org.example.functions.WordCountFunction \
   --tenant public \
   --namespace default \
   --name word-count \
@@ -148,7 +148,7 @@ $ bin/pulsar-functions localrun \
   --inputs persistent://public/default/test_src \
   --output persistent://public/default/test_result \
   --jar examples/api-examples.jar \
-  --className org.apache.pulsar.functions.api.examples.ExclamationFunction
+  --classname org.apache.pulsar.functions.api.examples.ExclamationFunction
 ```
 
 ## Fully Qualified Function Name (FQFN)
@@ -172,7 +172,7 @@ If you're supplying a YAML configuration, you must specify a path to the file on
 
 ```bash
 $ bin/pulsar-admin functions create \
-  --functionConfigFile ./my-function.yaml
+  --function-config-file ./my-function.yaml
 ```
 
 And here's an example `my-function.yaml` file:
@@ -277,7 +277,7 @@ If you run a Pulsar Function in **local run** mode, it will run on the machine f
 ```bash
 $ bin/pulsar-admin functions localrun \
   --py myfunc.py \
-  --className myfunc.SomeFunction \
+  --classname myfunc.SomeFunction \
   --inputs persistent://public/default/input-1 \
   --output persistent://public/default/output-1
 ```
@@ -286,7 +286,7 @@ By default, the function will connect to a Pulsar cluster running on the same ma
 
 ```bash
 $ bin/pulsar-admin functions localrun \
-  --brokerServiceUrl pulsar://my-cluster-host:6650 \
+  --broker-service-url pulsar://my-cluster-host:6650 \
   # Other function parameters
 ```
 
@@ -297,7 +297,7 @@ When you run a Pulsar Function in **cluster mode**, the function code will be up
 ```bash
 $ bin/pulsar-admin functions create \
   --py myfunc.py \
-  --className myfunc.SomeFunction \
+  --classname myfunc.SomeFunction \
   --inputs persistent://public/default/input-1 \
   --output persistent://public/default/output-1
 ```
@@ -316,7 +316,7 @@ $ bin/pulsar-admin functions create \
   --tenant public \
   --namespace default \
   --py func.py \
-  --className func.ParallelFunction \
+  --classname func.ParallelFunction \
   --parallelism 5
 ```
 
@@ -335,7 +335,7 @@ Here's an example function creation command that allocates 8 cores, 8 GB of RAM,
 ```bash
 $ bin/pulsar-admin functions create \
   --jar target/my-functions.jar \
-  --className org.example.functions.MyFunction \
+  --classname org.example.functions.MyFunction \
   --cpu 8 \
   --ram 8589934592 \
   --disk 10737418240
@@ -350,7 +350,7 @@ Pulsar Functions created using the [Pulsar Functions SDK](#the-pulsar-functions-
 ```bash
 $ bin/pulsar-admin functions create \
   --name my-func-1 \
-  --logTopic persistent://public/default/my-func-1-log \
+  --log-topic persistent://public/default/my-func-1-log \
   # Other configs
 ```
 
@@ -378,7 +378,7 @@ Here's an example of passing a user configuration to a function:
 
 ```bash
 $ bin/pulsar-admin functions create \
-  --userConfig '{"key-1":"value-1","key-2","value-2"}' \
+  --user-config '{"key-1":"value-1","key-2","value-2"}' \
   # Other configs
 ```
 
@@ -416,7 +416,7 @@ $ bin/pulsar-admin functions trigger \
   --tenant public \
   --namespace default \
   --name reverse-func \
-  --triggerValue "snoitcnuf raslup ot emoclew"
+  --trigger-value "snoitcnuf raslup ot emoclew"
 ```
 
 That should return `welcome to pulsar functions` as the console output.
@@ -438,7 +438,7 @@ This command, for example, would run a function in [cluster mode](#cluster-run-m
 ```bash
 $ bin/pulsar-admin functions create \
   --name my-effectively-once-function \
-  --processingGuarantees EFFECTIVELY_ONCE \
+  --processing-guarantees EFFECTIVELY_ONCE \
   # Other function configs
 ```
 
diff --git a/site2/docs/functions-quickstart.md b/site2/docs/functions-quickstart.md
index 9d3690e..3523216 100644
--- a/site2/docs/functions-quickstart.md
+++ b/site2/docs/functions-quickstart.md
@@ -48,7 +48,7 @@ A JAR file containing this and several other functions (written in Java) is incl
 ```bash
 $ bin/pulsar-admin functions localrun \
   --jar examples/api-examples.jar \
-  --className org.apache.pulsar.functions.api.examples.ExclamationFunction \
+  --classname org.apache.pulsar.functions.api.examples.ExclamationFunction \
   --inputs persistent://public/default/exclamation-input \
   --output persistent://public/default/exclamation-output \
   --name exclamation
@@ -104,7 +104,7 @@ This command, for example, would deploy the same exclamation function we ran loc
 ```bash
 $ bin/pulsar-admin functions create \
   --jar examples/api-examples.jar \
-  --className org.apache.pulsar.functions.api.examples.ExclamationFunction \
+  --classname org.apache.pulsar.functions.api.examples.ExclamationFunction \
   --inputs persistent://public/default/exclamation-input \
   --output persistent://public/default/exclamation-output \
   --name exclamation
@@ -171,7 +171,7 @@ As we can see, the parallelism of the function is 1, meaning that only one insta
 ```bash
 $ bin/pulsar-admin functions update \
   --jar examples/api-examples.jar \
-  --className org.apache.pulsar.functions.api.examples.ExclamationFunction \
+  --classname org.apache.pulsar.functions.api.examples.ExclamationFunction \
   --inputs persistent://public/default/exclamation-input \
   --output persistent://public/default/exclamation-output \
   --tenant public \
@@ -235,7 +235,7 @@ Here, the `process` method defines the processing logic of the Pulsar Function.
 ```bash
 $ bin/pulsar-admin functions create \
   --py reverse.py \
-  --className reverse \
+  --class-name reverse \
   --inputs persistent://public/default/backwards \
   --output persistent://public/default/forwards \
   --tenant public \
@@ -250,7 +250,7 @@ $ bin/pulsar-admin functions trigger \
   --name reverse \
   --tenant public \
   --namespace default \
-  --triggerValue "sdrawrof won si tub sdrawkcab saw gnirts sihT"
+  --trigger-value "sdrawrof won si tub sdrawkcab saw gnirts sihT"
 ```
 
 You should get this output:
diff --git a/site2/docs/io-managing.md b/site2/docs/io-managing.md
index 5807924..72210d1 100644
--- a/site2/docs/io-managing.md
+++ b/site2/docs/io-managing.md
@@ -54,22 +54,22 @@ Pulsar connectors can be managed using the [`source`](reference-pulsar-admin.md#
 You can submit a source to be run in an existing Pulsar cluster using a command of this form:
 
 ```bash
-$ ./bin/pulsar-admin source create --className  <classname> --jar <jar-location> --tenant <tenant> --namespace <namespace> --name <source-name> --destinationTopicName <output-topic>
+$ ./bin/pulsar-admin source create --classname  <classname> --archive <jar-location> --tenant <tenant> --namespace <namespace> --name <source-name> --destination-topic-name <output-topic>
 ```
 
 Here’s an example command:
 
 ```bash
-bin/pulsar-admin source create --className org.apache.pulsar.io.twitter.TwitterFireHose --jar ~/application.jar --tenant test --namespace ns1 --name twitter-source --destinationTopicName twitter_data
+bin/pulsar-admin source create --classname org.apache.pulsar.io.twitter.TwitterFireHose --archive ~/application.jar --tenant test --namespace ns1 --name twitter-source --destination-topic-name twitter_data
 ```
 
 Instead of submitting a source to run on an existing Pulsar cluster, you alternatively can run a source as a process on your local machine:
 
 ```bash
-bin/pulsar-admin source localrun --className  org.apache.pulsar.io.twitter.TwitterFireHose --jar ~/application.jar --tenant test --namespace ns1 --name twitter-source --destinationTopicName twitter_data
+bin/pulsar-admin source localrun --classname  org.apache.pulsar.io.twitter.TwitterFireHose --archive ~/application.jar --tenant test --namespace ns1 --name twitter-source --destination-topic-name twitter_data
 ```
 
-If you are submitting a built-in source, you don't need to specify `--className` and `--jar`.
+If you are submitting a built-in source, you don't need to specify `--classname` and `--archive`.
 You can simply specify the source type `--source-type`. The command to submit a built-in source is
 in following form:
 
@@ -78,7 +78,7 @@ in following form:
     --tenant <tenant> \
     --namespace <namespace> \
     --name <source-name> \
-    --destinationTopicName <input-topics> \
+    --destination-topic-name <input-topics> \
     --source-type <source-type>
 ```
 
@@ -89,7 +89,7 @@ Here's an example to submit a Kafka source:
     --tenant test-tenant \
     --namespace test-namespace \
     --name test-kafka-source \
-    --destinationTopicName pulsar_sink_topic \
+    --destination-topic-name pulsar_sink_topic \
     --source-type kafka
 ```
 
@@ -98,22 +98,22 @@ Here's an example to submit a Kafka source:
 You can submit a sink to be run in an existing Pulsar cluster using a command of this form:
 
 ```bash
-./bin/pulsar-admin sink create --className  <classname> --jar <jar-location> --tenant test --namespace <namespace> --name <sink-name> --inputs <input-topics>
+./bin/pulsar-admin sink create --classname  <classname> --archive <jar-location> --tenant test --namespace <namespace> --name <sink-name> --inputs <input-topics>
 ```
 
 Here’s an example command:
 
 ```bash
-./bin/pulsar-admin sink create --className  org.apache.pulsar.io.cassandra --jar ~/application.jar --tenant test --namespace ns1 --name cassandra-sink --inputs test_topic
+./bin/pulsar-admin sink create --classname  org.apache.pulsar.io.cassandra --archive ~/application.jar --tenant test --namespace ns1 --name cassandra-sink --inputs test_topic
 ```
 
 Instead of submitting a sink to run on an existing Pulsar cluster, you alternatively can run a sink as a process on your local machine:
 
 ```bash
-./bin/pulsar-admin sink localrun --className  org.apache.pulsar.io.cassandra --jar ~/application.jar --tenant test --namespace ns1 --name cassandra-sink --inputs test_topic
+./bin/pulsar-admin sink localrun --classname  org.apache.pulsar.io.cassandra --archive ~/application.jar --tenant test --namespace ns1 --name cassandra-sink --inputs test_topic
 ```
 
-If you are submitting a built-in sink, you don't need to specify `--className` and `--jar`.
+If you are submitting a built-in sink, you don't need to specify `--classname` and `--archive`.
 You can simply specify the sink type `--sink-type`. The command to submit a built-in sink is
 in following form:
 
diff --git a/site2/docs/io-quickstart.md b/site2/docs/io-quickstart.md
index d426a1c..4b40f6b 100644
--- a/site2/docs/io-quickstart.md
+++ b/site2/docs/io-quickstart.md
@@ -233,7 +233,7 @@ bin/pulsar-admin sink create \
     --namespace default \
     --name cassandra-test-sink \
     --sink-type cassandra \
-    --sinkConfigFile examples/cassandra-sink.yml \
+    --sink-config-file examples/cassandra-sink.yml \
     --inputs test_cassandra
 ```
 
diff --git a/site2/docs/reference-pulsar-admin.md b/site2/docs/reference-pulsar-admin.md
index 48fec1a..459afce 100644
--- a/site2/docs/reference-pulsar-admin.md
+++ b/site2/docs/reference-pulsar-admin.md
@@ -306,24 +306,35 @@ Options
 |`--cpu`|The CPU to allocate to each function instance (in number of cores)||
 |`--ram`|The RAM to allocate to each function instance (in bytes)||
 |`--disk`|The disk space to allocate to each function instance (in bytes)||
-|`--brokerServiceUrl `|The URL of the Pulsar broker||
-|`--className`|The name of the function’s class||
-|`--customSerdeInputs`|A map of the input topic to SerDe name||
-|`--functionConfigFile`|The path of the YAML config file used to configure the function||
+|`--auto-ack`|Let the functions framework manage acking||
+|`--broker-service-url `|The URL of the Pulsar broker||
+|`--classname`|The name of the function’s class||
+|`--custom-serde-inputs`|A map of the input topic to SerDe name||
+|`--client-auth-params`|Client Authentication Params||
+|`--function-config-file`|The path of the YAML config file used to configure the function||
+|`--hostname-verification-enabled`|Enable Hostname verification||
+|`--instance-id-offset`|Instance ids will be assigned starting from this offset||
 |`--inputs`|The input topics for the function (as a comma-separated list if more than one topic is desired)||
-|`--logTopic`|The topic to which logs from this function are published||
+|`--log-topic`|The topic to which logs from this function are published||
 |`--jar`|A path to the JAR file for the function (if the function is written in Java)||
-|`--name`|The name of the function|The value specified by --className|
+|`--name`|The name of the function||
 |`--namespace`|The function’s namespace||
 |`--output`|The name of the topic to which the function publishes its output (if any)||
-|`--outputSerdeClassName`|The SerDe class used for the function’s output||
+|`--output-serde-classname`|The SerDe class used for the function’s output||
 |`--parallelism`|The function’s parallelism factor, i.e. the number of instances of the function to run|1|
-|`--processingGuarantees`|The processing guarantees applied to the function. Can be one of: ATLEAST_ONCE, ATMOST_ONCE, or EFFECTIVELY_ONCE|ATLEAST_ONCE|
+|`--processing-guarantees`|The processing guarantees applied to the function. Can be one of: ATLEAST_ONCE, ATMOST_ONCE, or EFFECTIVELY_ONCE|ATLEAST_ONCE|
 |`--py`|The path of the Python file containing the function’s processing logic (if the function is written in Python)||
-|`--stateStorageServiceUrl`|The service URL for the function’s state storage (if the function uses a storage system different from the Apache BookKeeper cluster used by Pulsar)||
-|`--subscriptionType`|The subscription type used by the function when consuming messages on the input topic(s). Can be either SHARED or EXCLUSIVE|SHARED|
+|`--schema-type`|Schema Type to be used for storing output messages||
+|`--skip-output`|Do we supress writing to the output topic||
+|`--sliding-interval-count`|Number of messages after which the window ends||
+|`--sliding-interval-duration-ms`|The time duration after which the window slides||
+|`--state-storage-service-url`|The service URL for the function’s state storage (if the function uses a storage system different from the Apache BookKeeper cluster used by Pulsar)||
+|`--subscription-type`|The subscription type used by the function when consuming messages on the input topic(s). Can be either SHARED or EXCLUSIVE|SHARED|
 |`--tenant`|The function’s tenant||
-|`--userConfig`|A user-supplied config value, set as a key/value pair. You can set multiple user config values.||
+|`--topics-pattern`|The topic pattern to consume from list of topics under a namespace that match the pattern||
+|`--user-config`|A user-supplied config value, set as a key/value pair. You can set multiple user config values.||
+|`--window-length-count`|The number of messages per window.||
+|`--window-length-duration-ms`|The time duration of the window in milliseconds.||
 
 
 ### `create`
@@ -340,24 +351,30 @@ Options
 |`--cpu`|The CPU to allocate to each function instance (in number of cores)||
 |`--ram`|The RAM to allocate to each function instance (in bytes)||
 |`--disk`|The disk space to allocate to each function instance (in bytes)||
-|`--brokerServiceUrl `|The URL of the Pulsar broker||
-|`--className`|The name of the function’s class||
-|`--customSerdeInputs`|A map of the input topic to SerDe name||
-|`--functionConfigFile`|The path of the YAML config file used to configure the function||
+|`--auto-ack`|Let the functions framework manage acking||
+|`--classname`|The name of the function’s class||
+|`--custom-serde-inputs`|A map of the input topic to SerDe name||
+|`--function-config-file`|The path of the YAML config file used to configure the function||
 |`--inputs`|The input topics for the function (as a comma-separated list if more than one topic is desired)||
-|`--logTopic`|The topic to which logs from this function are published||
+|`--log-topic`|The topic to which logs from this function are published||
 |`--jar`|A path to the JAR file for the function (if the function is written in Java)||
-|`--name`|The name of the function|The value specified by --className|
+|`--name`|The name of the function||
 |`--namespace`|The function’s namespace||
 |`--output`|The name of the topic to which the function publishes its output (if any)||
-|`--outputSerdeClassName`|The SerDe class used for the function’s output||
+|`--output-serde-classname`|The SerDe class used for the function’s output||
 |`--parallelism`|The function’s parallelism factor, i.e. the number of instances of the function to run|1|
-|`--processingGuarantees`|The processing guarantees applied to the function. Can be one of: ATLEAST_ONCE, ATMOST_ONCE, or EFFECTIVELY_ONCE|ATLEAST_ONCE|
+|`--processing-guarantees`|The processing guarantees applied to the function. Can be one of: ATLEAST_ONCE, ATMOST_ONCE, or EFFECTIVELY_ONCE|ATLEAST_ONCE|
 |`--py`|The path of the Python file containing the function’s processing logic (if the function is written in Python)||
-|`--stateStorageServiceUrl`|The service URL for the function’s state storage (if the function uses a storage system different from the Apache BookKeeper cluster used by Pulsar)||
-|`--subscriptionType`|The subscription type used by the function when consuming messages on the input topic(s). Can be either SHARED or EXCLUSIVE|SHARED|
+|`--schema-type`|Schema Type to be used for storing output messages||
+|`--skip-output`|Do we supress writing to the output topic||
+|`--sliding-interval-count`|Number of messages after which the window ends||
+|`--sliding-interval-duration-ms`|The time duration after which the window slides||
+|`--subscription-type`|The subscription type used by the function when consuming messages on the input topic(s). Can be either SHARED or EXCLUSIVE|SHARED|
 |`--tenant`|The function’s tenant||
-|`--userConfig`|A user-supplied config value, set as a key/value pair. You can set multiple user config values.||
+|`--topics-pattern`|The topic pattern to consume from list of topics under a namespace that match the pattern||
+|`--user-config`|A user-supplied config value, set as a key/value pair. You can set multiple user config values.||
+|`--window-length-count`|The number of messages per window.||
+|`--window-length-duration-ms`|The time duration of the window in milliseconds.||
 
 
 ### `delete`
@@ -388,22 +405,34 @@ $ pulsar-admin functions update options
 Options
 |Flag|Description|Default|
 |---|---|---|
-|`--className`|The name of the function’s class||
-|`--customSerdeInputs`|A map of the input topic to SerDe name||
-|`--functionConfigFile`|The path of the YAML config file used to configure the function||
+|`--cpu`|The CPU to allocate to each function instance (in number of cores)||
+|`--ram`|The RAM to allocate to each function instance (in bytes)||
+|`--disk`|The disk space to allocate to each function instance (in bytes)||
+|`--auto-ack`|Let the functions framework manage acking||
+|`--classname`|The name of the function’s class||
+|`--custom-serde-inputs`|A map of the input topic to SerDe name||
+|`--function-config-file`|The path of the YAML config file used to configure the function||
 |`--inputs`|The input topics for the function (as a comma-separated list if more than one topic is desired)||
-|`--logTopic`|The topic to which logs from this function are published||
+|`--log-topic`|The topic to which logs from this function are published||
 |`--jar`|A path to the JAR file for the function (if the function is written in Java)||
-|`--name`|The name of the function|The value specified by --className|
+|`--name`|The name of the function||
 |`--namespace`|The function’s namespace||
 |`--output`|The name of the topic to which the function publishes its output (if any)||
-|`--outputSerdeClassName`|The SerDe class used for the function’s output||
+|`--output-serde-classname`|The SerDe class used for the function’s output||
 |`--parallelism`|The function’s parallelism factor, i.e. the number of instances of the function to run|1|
-|`--processingGuarantees`|The processing guarantees applied to the function. Can be one of: ATLEAST_ONCE, ATMOST_ONCE, or EFFECTIVELY_ONCE|ATLEAST_ONCE|
+|`--processing-guarantees`|The processing guarantees applied to the function. Can be one of: ATLEAST_ONCE, ATMOST_ONCE, or EFFECTIVELY_ONCE|ATLEAST_ONCE|
 |`--py`|The path of the Python file containing the function’s processing logic (if the function is written in Python)||
-|`--subscriptionType`|The subscription type used by the function when consuming messages on the input topic(s). Can be either SHARED or EXCLUSIVE|SHARED|
+|`--schema-type`|Schema Type to be used for storing output messages||
+|`--skip-output`|Do we supress writing to the output topic||
+|`--sliding-interval-count`|Number of messages after which the window ends||
+|`--sliding-interval-duration-ms`|The time duration after which the window slides||
+|`--subscription-type`|The subscription type used by the function when consuming messages on the input topic(s). Can be either SHARED or EXCLUSIVE|SHARED|
 |`--tenant`|The function’s tenant||
-|`--userConfig`|A user-supplied config value, set as a key/value pair. You can set multiple user config values.||
+|`--topics-pattern`|The topic pattern to consume from list of topics under a namespace that match the pattern||
+|`--user-config`|A user-supplied config value, set as a key/value pair. You can set multiple user config values.||
+|`--window-length-count`|The number of messages per window.||
+|`--window-length-duration-ms`|The time duration of the window in milliseconds.||
+
 
 ### `get`
 Fetch information about an existing Pulsar Function
@@ -421,6 +450,40 @@ Options
 |`--tenant`|The tenant of the function||
 
 
+### `restart`
+Restarts either all instances or one particular instance of a function
+
+Usage
+```bash
+$ pulsar-admin functions restart options
+```
+
+Options
+|Flag|Description|Default|
+|---|---|---|
+|`--name`|The name of the function||
+|`--namespace`|The namespace of the function||
+|`--tenant`|The tenant of the function||
+|`--instance-id`|The function instanceId; restart all instances if instance-id is not provided||
+
+
+### `stop`
+Temporary stops function instance. (If worker restarts then it reassigns and starts functiona again)
+
+Usage
+```bash
+$ pulsar-admin functions stop options
+```
+
+Options
+|Flag|Description|Default|
+|---|---|---|
+|`--name`|The name of the function||
+|`--namespace`|The namespace of the function||
+|`--tenant`|The tenant of the function||
+|`--instance-id`|The function instanceId; stop all instances if instance-id is not provided||
+
+
 ### `getstatus`
 Get the status of an existing Pulsar Function
 
@@ -485,8 +548,8 @@ Options
 |`--name`|The name of the Pulsar Function to trigger||
 |`--namespace`|The namespace of the Pulsar Function to trigger||
 |`--tenant`|The tenant of the Pulsar Function to trigger||
-|`--triggerFile`|The path to the file containing the data with which the Pulsar Function is to be triggered||
-|`--triggerValue`|The value with which the Pulsar Function is to be triggered||
+|`--trigger-file`|The path to the file containing the data with which the Pulsar Function is to be triggered||
+|`--trigger-value`|The value with which the Pulsar Function is to be triggered||
 
 
 ## `namespaces`
@@ -914,8 +977,10 @@ $ pulsar-admin sink subcommand
 
 Subcommands
 * `create`
+* `update`
 * `delete`
 * `localrun`
+* `available-sinks`
 
 
 ### `create`
@@ -929,19 +994,52 @@ $ pulsar-admin sink create options
 Options
 |Flag|Description|Default|
 |----|---|---|
-|`--className`|The sink’s Java class name||
+|`--classname`|The sink’s Java class name||
 |`--cpu`|The CPU (in cores) that needs to be allocated per sink instance (applicable only to the Docker runtime)||
-|`--customSerdeInputs`|The map of input topics to SerDe class names (as a JSON string)||
+|`--custom-serde-inputs`|The map of input topics to SerDe class names (as a JSON string)||
+|`--custom-schema-inputs`|The map of input topics to Schema types or class names (as a JSON string)||
 |`--disk`|The disk (in bytes) that needs to be allocated per sink instance (applicable only to the Docker runtime)||
 |`--inputs`|The sink’s input topic(s) (multiple topics can be specified as a comma-separated list)||
-|`--jar`|Path to the Java jar file for the sink||
+|`--archive`|Path to the archive file for the sink||
 |`--name`|The sink’s name||
 |`--namespace`|The sink’s namespace||
 |`--parallelism`|“The sink’s parallelism factor (i.e. the number of sink instances to run).”||
-|`--processingGuarantees`|“The processing guarantees (aka delivery semantics) applied to the sink. Available values: ATLEAST_ONCE, ATMOST_ONCE, EFFECTIVELY_ONCE.”||
+|`--processing-guarantees`|“The processing guarantees (aka delivery semantics) applied to the sink. Available values: ATLEAST_ONCE, ATMOST_ONCE, EFFECTIVELY_ONCE.”||
 |`--ram`|The RAM (in bytes) that needs to be allocated per sink instance (applicable only to the Docker runtime)||
-|`--sinkConfig`|Sink config key/values||
-|`--sinkConfigFile`|The path to a YAML config file specifying the sink’s configuration||
+|`--sink-config`|Sink config key/values||
+|`--sink-config-file`|The path to a YAML config file specifying the sink’s configuration||
+|`--sink-type`|The built-in sinks's connector provider||
+|`--topics-pattern`|TopicsPattern to consume from list of topics under a namespace that match the pattern.||
+|`--tenant`|The sink’s tenant||
+
+
+### `update`
+Submit a Pulsar IO sink connector to run in a Pulsar cluster
+
+Usage
+```bash
+$ pulsar-admin sink update options
+```
+
+Options
+|Flag|Description|Default|
+|----|---|---|
+|`--classname`|The sink’s Java class name||
+|`--cpu`|The CPU (in cores) that needs to be allocated per sink instance (applicable only to the Docker runtime)||
+|`--custom-serde-inputs`|The map of input topics to SerDe class names (as a JSON string)||
+|`--custom-schema-inputs`|The map of input topics to Schema types or class names (as a JSON string)||
+|`--disk`|The disk (in bytes) that needs to be allocated per sink instance (applicable only to the Docker runtime)||
+|`--inputs`|The sink’s input topic(s) (multiple topics can be specified as a comma-separated list)||
+|`--archive`|Path to the archive file for the sink||
+|`--name`|The sink’s name||
+|`--namespace`|The sink’s namespace||
+|`--parallelism`|“The sink’s parallelism factor (i.e. the number of sink instances to run).”||
+|`--processing-guarantees`|“The processing guarantees (aka delivery semantics) applied to the sink. Available values: ATLEAST_ONCE, ATMOST_ONCE, EFFECTIVELY_ONCE.”||
+|`--ram`|The RAM (in bytes) that needs to be allocated per sink instance (applicable only to the Docker runtime)||
+|`--sink-config`|Sink config key/values||
+|`--sink-config-file`|The path to a YAML config file specifying the sink’s configuration||
+|`--sink-type`|The built-in sinks's connector provider||
+|`--topics-pattern`|TopicsPattern to consume from list of topics under a namespace that match the pattern.||
 |`--tenant`|The sink’s tenant||
 
 
@@ -972,23 +1070,34 @@ $ pulsar-admin sink localrun options
 Options
 |Flag|Description|Default|
 |----|---|---|
-|`--brokerServiceUrl`|The URL for the Pulsar broker||
-|`--className`|The sink’s Java class name||
+|`--broker-service-url`|The URL for the Pulsar broker||
+|`--classname`|The sink’s Java class name||
 |`--cpu`|The CPU (in cores) that needs to be allocated per sink instance (applicable only to the Docker runtime)||
-|`--customSerdeInputs`|The map of input topics to SerDe class names (as a JSON string)||
+|`--custom-serde-inputs`|The map of input topics to SerDe class names (as a JSON string)||
+|`--custom-schema-inputs`|The map of input topics to Schema types or class names (as a JSON string)||
 |`--disk`|The disk (in bytes) that needs to be allocated per sink instance (applicable only to the Docker runtime)||
 |`--inputs`|The sink’s input topic(s) (multiple topics can be specified as a comma-separated list)||
-|`--jar`|Path to the Java jar file for the sink||
+|`--archive`|Path to the archive file for the sink||
 |`--name`|The sink’s name||
 |`--namespace`|The sink’s namespace||
 |`--parallelism`|“The sink’s parallelism factor (i.e. the number of sink instances to run).”||
-|`--processingGuarantees`|“The processing guarantees (aka delivery semantics) applied to the sink. Available values: ATLEAST_ONCE, ATMOST_ONCE, EFFECTIVELY_ONCE.”||
+|`--processing-guarantees`|“The processing guarantees (aka delivery semantics) applied to the sink. Available values: ATLEAST_ONCE, ATMOST_ONCE, EFFECTIVELY_ONCE.”||
 |`--ram`|The RAM (in bytes) that needs to be allocated per sink instance (applicable only to the Docker runtime)||
-|`--sinkConfig`|Sink config key/values||
-|`--sinkConfigFile`|The path to a YAML config file specifying the sink’s configuration||
+|`--sink-config`|Sink config key/values||
+|`--sink-config-file`|The path to a YAML config file specifying the sink’s configuration||
+|`--sink-type`|The built-in sinks's connector provider||
+|`--topics-pattern`|TopicsPattern to consume from list of topics under a namespace that match the pattern.||
 |`--tenant`|The sink’s tenant||
 
 
+### `available-sinks`
+Get a list of all built-in sink connectors
+
+Usage
+```bash
+$ pulsar-admin sink available-sinks
+```
+
 
 ## `source`
 An interface for managing Pulsar IO sources (ingress data into Pulsar)
@@ -1000,8 +1109,10 @@ $ pulsar-admin source subcommand
 
 Subcommands
 * `create`
+* `update`
 * `delete`
 * `localrun`
+* `available-sources`
 
 
 ### `create`
@@ -1015,19 +1126,50 @@ $ pulsar-admin source create options
 Options
 |Flag|Description|Default|
 |----|---|---|
-|`--className`|The source’s Java class name||
+|`--classname`|The source’s Java class name||
 |`--cpu`|The CPU (in cores) that needs to be allocated per source instance (applicable only to the Docker runtime)||
-|`--deserializationClassName`|The SerDe classname for the source||
-|`--destinationTopicName`|The Pulsar topic to which data is sent||
+|`--deserialization-classname`|The SerDe classname for the source||
+|`--destination-topic-name`|The Pulsar topic to which data is sent||
 |`--disk`|The disk (in bytes) that needs to be allocated per source instance (applicable only to the Docker runtime)||
-|`--jar`|Path to the Java jar file for the source||
+|`--archive`|The path to the NAR archive for the Source||
 |`--name`|The source’s name||
 |`--namespace`|The source’s namespace||
 |`--parallelism`|The source’s parallelism factor (i.e. the number of source instances to run).||
-|`--processingGuarantees`|“The processing guarantees (aka delivery semantics) applied to the source. Available values: ATLEAST_ONCE, ATMOST_ONCE, EFFECTIVELY_ONCE.”||
+|`--processing-guarantees`|“The processing guarantees (aka delivery semantics) applied to the source. Available values: ATLEAST_ONCE, ATMOST_ONCE, EFFECTIVELY_ONCE.”||
 |`--ram`|The RAM (in bytes) that needs to be allocated per source instance (applicable only to the Docker runtime)||
-|`--sourceConfig`|Source config key/values||
-|`--sourceConfigFile`|The path to a YAML config file specifying the source’s configuration||
+|`--schema-type`|The schema type (either a builtin schema like 'avro', 'json', etc, or custom Schema class name to be used to encode messages emitted from the source||
+|`--source-type`|One of the built-in source's connector provider||
+|`--source-config`|Source config key/values||
+|`--source-config-file`|The path to a YAML config file specifying the source’s configuration||
+|`--tenant`|The source’s tenant||
+
+
+### `update`
+Update a already submitted Pulsar IO source connector
+
+Usage
+```bash
+$ pulsar-admin source update options
+```
+
+Options
+|Flag|Description|Default|
+|----|---|---|
+|`--classname`|The source’s Java class name||
+|`--cpu`|The CPU (in cores) that needs to be allocated per source instance (applicable only to the Docker runtime)||
+|`--deserialization-classname`|The SerDe classname for the source||
+|`--destination-topic-name`|The Pulsar topic to which data is sent||
+|`--disk`|The disk (in bytes) that needs to be allocated per source instance (applicable only to the Docker runtime)||
+|`--archive`|The path to the NAR archive for the Source||
+|`--name`|The source’s name||
+|`--namespace`|The source’s namespace||
+|`--parallelism`|The source’s parallelism factor (i.e. the number of source instances to run).||
+|`--processing-guarantees`|“The processing guarantees (aka delivery semantics) applied to the source. Available values: ATLEAST_ONCE, ATMOST_ONCE, EFFECTIVELY_ONCE.”||
+|`--ram`|The RAM (in bytes) that needs to be allocated per source instance (applicable only to the Docker runtime)||
+|`--schema-type`|The schema type (either a builtin schema like 'avro', 'json', etc, or custom Schema class name to be used to encode messages emitted from the source||
+|`--source-type`|One of the built-in source's connector provider||
+|`--source-config`|Source config key/values||
+|`--source-config-file`|The path to a YAML config file specifying the source’s configuration||
 |`--tenant`|The source’s tenant||
 
 
@@ -1058,22 +1200,32 @@ $ pulsar-admin source localrun options
 Options
 |Flag|Description|Default|
 |----|---|---|
-|`--className`|The source’s Java class name||
+|`--classname`|The source’s Java class name||
 |`--cpu`|The CPU (in cores) that needs to be allocated per source instance (applicable only to the Docker runtime)||
-|`--deserializationClassName`|The SerDe classname for the source||
-|`--destinationTopicName`|The Pulsar topic to which data is sent||
+|`--deserialization-classname`|The SerDe classname for the source||
+|`--destination-topic-name`|The Pulsar topic to which data is sent||
 |`--disk`|The disk (in bytes) that needs to be allocated per source instance (applicable only to the Docker runtime)||
-|`--jar`|Path to the Java jar file for the source||
+|`--archive`|The path to the NAR archive for the Source||
 |`--name`|The source’s name||
 |`--namespace`|The source’s namespace||
 |`--parallelism`|The source’s parallelism factor (i.e. the number of source instances to run).||
-|`--processingGuarantees`|“The processing guarantees (aka delivery semantics) applied to the source. Available values: ATLEAST_ONCE, ATMOST_ONCE, EFFECTIVELY_ONCE.”||
+|`--processing-guarantees`|“The processing guarantees (aka delivery semantics) applied to the source. Available values: ATLEAST_ONCE, ATMOST_ONCE, EFFECTIVELY_ONCE.”||
 |`--ram`|The RAM (in bytes) that needs to be allocated per source instance (applicable only to the Docker runtime)||
-|`--sourceConfig`|Source config key/values||
-|`--sourceConfigFile`|The path to a YAML config file specifying the source’s configuration||
+|`--schema-type`|The schema type (either a builtin schema like 'avro', 'json', etc, or custom Schema class name to be used to encode messages emitted from the source||
+|`--source-type`|One of the built-in source's connector provider||
+|`--source-config`|Source config key/values||
+|`--source-config-file`|The path to a YAML config file specifying the source’s configuration||
 |`--tenant`|The source’s tenant||
 
 
+### `available-sources`
+Get a list of all built-in source connectors
+
+Usage
+```bash
+$ pulsar-admin source available-sources
+```
+
 
 ## `topics`
 Operations for managing Pulsar topics (both persistent and non persistent)


Mime
View raw message