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 <sanjee...@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)
