Re: [DISCUSS] Proceeding with PIP-62 plan, before Apache Pulsar 2.10.0 is released

[Enrico Olivelli]

Sijie,
> Sorry. When you say "we discussed", who are "we"? Is it DataStax?
There have been discussions on the ML and we discussed this also in
Community meetings.
So "we" is this community

> I believe we want to keep SQL until the code change lands in Trino.
Because
> there are still users using this component.

If we don't want to remove Presto then we have to at least move to the
latest version, that requires JDK11.

My understanding is that Lari is willing to help in completing this work.
When we discussed this, probably something like 1 year ago, Lari did not
have write permissions and he could not help.

There is not only Presto, we had to move all the Connectors and so change
the build process for the Pulsar "-all" docker image
We can defer Presto and move forward with the Connectors

Enrico



Il giorno gio 23 dic 2021 alle ore 06:34 Michael Marshall <
mmarsh...@apache.org> ha scritto:

> > I am volunteering to making the changes as per the PIP-62 plan.
>
> I think Lari is proposing to complete the work to move the
> Pulsar SQL code base to the repositories defined in PIP 62.
>
> Assuming that is what he meant, I am +1 on completing that now.
> Based on reading through the mailing list threads Lari referenced, we
> delayed moving the code base to the other repos with the hope that
> contributing the code to Trino/Presto would be done before the 2.8.0
> release. I think we should move forward with the initial PIP instead
> of waiting for the Trino PR to get merged.
>
> - Michael
>
> On Wed, Dec 22, 2021 at 6:39 PM Sijie Guo  wrote:
> >
> > Sorry. When you say "we discussed", who are "we"? Is it DataStax?
> >
> > I believe we want to keep SQL until the code change lands in Trino.
> Because
> > there are still users using this component.
> >
> > - Sijie
> >
> > On Tue, Dec 21, 2021 at 11:34 PM Enrico Olivelli 
> > wrote:
> >
> > > Lari,
> > >
> > > Il giorno mer 22 dic 2021 alle ore 08:31 Lari Hotari <
> lhot...@apache.org>
> > > ha scritto:
> > >
> > > > Dear Pulsar community members,
> > > >
> > > > PIP-62[1], "PIP 62: Move connectors, adapters and Pulsar Presto to
> > > separate
> > > > repositories" was created in April 2020. The repositories for
> > > > pulsar-connectors, pulsar-adapters and pulsar-sql were created about
> a
> > > year
> > > > ago [2].
> > > >
> > > > I'd like to propose that we continue with the PIP-62 plan asap,
> before
> > > > Apache Pulsar 2.10.0 is released.
> > > >
> > > > I'm also suggesting that we drop Pulsar SQL from apache/pulsar
> without
> > > > waiting for the Trino Pulsar PR [3] being completed.
> > > >
> > > > I am volunteering to making the changes as per the PIP-62 plan.
> > > > When can we proceed with the plan? Do we need an explicit vote on the
> > > > mailing list about this?
> > > >
> > >
> > > We discussed this many times in the past year.
> > > I believe that there is no need to wait
> > >
> > > Enrico
> > >
> > >
> > >
> > > >
> > > > BR,
> > > >
> > > > Lari
> > > >
> > > > [1]
> > > >
> > > >
> > >
> https://github.com/apache/pulsar/wiki/PIP-62%3A-Move-connectors%2C-adapters-and-Pulsar-Presto-to-separate-repositories
> > > > [2]
> > > >
> > > >
> > >
> https://lists.apache.org/thread.html/r9e6ec742e2896da1f0ce7d4adc7cb84fc6db6dbf797732ccdd50fb86%40%3Cdev.pulsar.apache.org%3E
> > > > [3] https://github.com/trinodb/trino/pull/8020
> > > >
> > > > Other email threads:
> > > > * [Discuss] Don't include presto/trino in the normal Pulsar
> distribution
> > > -
> > > > https://lists.apache.org/thread/jn96tct54mn0tvdot62vdslrvs38fm6d
> > > > * Updates on Presto connector for PIP-62 -
> > > > https://lists.apache.org/thread/f9n6sc2mrboq5sxhjbr7gvdl8vqp9fpk
> > > >
> > >
>

Re: [DISCUSS] Proceeding with PIP-62 plan, before Apache Pulsar 2.10.0 is released

[Lari Hotari]

> I believe we want to keep SQL until the code change lands in Trino.
Because
there are still users using this component.

There have been multiple public dev@pulsar.apache.org discussions about
PIP-62 which was initialized in April 2020.
Those users using Pulsar SQL can keep on using Pulsar 2.8.x or 2.9.x until
the feature is available in Trino. Isn't that a viable option?

The Pulsar community is here to help with the work. What is the status of
Trino work? Are there tasks that need help? Is there any ETA for the
landing of code in Trino?
Could we resolve this together?

BR, Lari

On Thu, Dec 23, 2021 at 2:39 AM Sijie Guo  wrote:

> Sorry. When you say "we discussed", who are "we"? Is it DataStax?
>
> I believe we want to keep SQL until the code change lands in Trino. Because
> there are still users using this component.
>
> - Sijie
>
> On Tue, Dec 21, 2021 at 11:34 PM Enrico Olivelli 
> wrote:
>
> > Lari,
> >
> > Il giorno mer 22 dic 2021 alle ore 08:31 Lari Hotari  >
> > ha scritto:
> >
> > > Dear Pulsar community members,
> > >
> > > PIP-62[1], "PIP 62: Move connectors, adapters and Pulsar Presto to
> > separate
> > > repositories" was created in April 2020. The repositories for
> > > pulsar-connectors, pulsar-adapters and pulsar-sql were created about a
> > year
> > > ago [2].
> > >
> > > I'd like to propose that we continue with the PIP-62 plan asap, before
> > > Apache Pulsar 2.10.0 is released.
> > >
> > > I'm also suggesting that we drop Pulsar SQL from apache/pulsar without
> > > waiting for the Trino Pulsar PR [3] being completed.
> > >
> > > I am volunteering to making the changes as per the PIP-62 plan.
> > > When can we proceed with the plan? Do we need an explicit vote on the
> > > mailing list about this?
> > >
> >
> > We discussed this many times in the past year.
> > I believe that there is no need to wait
> >
> > Enrico
> >
> >
> >
> > >
> > > BR,
> > >
> > > Lari
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/apache/pulsar/wiki/PIP-62%3A-Move-connectors%2C-adapters-and-Pulsar-Presto-to-separate-repositories
> > > [2]
> > >
> > >
> >
> https://lists.apache.org/thread.html/r9e6ec742e2896da1f0ce7d4adc7cb84fc6db6dbf797732ccdd50fb86%40%3Cdev.pulsar.apache.org%3E
> > > [3] https://github.com/trinodb/trino/pull/8020
> > >
> > > Other email threads:
> > > * [Discuss] Don't include presto/trino in the normal Pulsar
> distribution
> > -
> > > https://lists.apache.org/thread/jn96tct54mn0tvdot62vdslrvs38fm6d
> > > * Updates on Presto connector for PIP-62 -
> > > https://lists.apache.org/thread/f9n6sc2mrboq5sxhjbr7gvdl8vqp9fpk
> > >
> >
>

[GitHub] [pulsar-manager] sourabhaggrawal opened a new pull request #436: Allow user to assign tenant as resource to role

[GitBox]

sourabhaggrawal opened a new pull request #436:
URL: https://github.com/apache/pulsar-manager/pull/436


   ### Motivation
   Improve Tenant/Namespace resource assignment workflow.

   * When assigning the resource to a role, it only let you choose from 
Namespace,Tenants,SCHEMA,Functions but does not allow the user to select 
TENANT. A user should have ability to choose tenant for a role and assign the 
role to a user. Based on which the user should be able to see the tenant it is 
assigned with. 
   
As of now we are also creating default tenant and roles with user's name 
when user is created. 
   In Next PR I will suggest a change where we do not create default tenant and 
role with username, Instead once a user is create let that be a manual 
excercise of creating/assigning a role & tenant to it.  *
   
   ### Modifications
   
   * changes in this PR include below fixes.
   1. Add TENANT as ResourceType along with Namepsace,Schema etc for 
Create/Edit Role.
   2. Include only tenants as resource while preparing the response from api 
/tenants in TenantsController.
   3. In Success LoginResponse, add the tenant as header which is assigned to 
user's role instead of tenant with user's name.
   
   ### Verifying this change
   
   - [ ] Make sure that the change passes the `./gradlew build` checks.
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-client-node] Matt-Esch commented on issue #99: Authenticating using a Token

[GitBox]

Matt-Esch commented on issue #99:
URL: 
https://github.com/apache/pulsar-client-node/issues/99#issuecomment-1000215683


   I am attempting an upgrade to node 16 which means fast-forwarding the 
version of pulsar-client-node we are using from 1.2.0 to 1.4.1, which comes 
with the minimum pulsar version requirement of 2.8.0. We find that upgrading to 
pulsar-client-node@v1.4.1 with pulsar 2.8.0 causes this handshake fail issue. 
We also find that remaining on pulsar-client-node@v1.2.0 and upgrading past 
pulsar >= 2.7.0 also causes the same issue, so this is likely to be a change in 
the underlying pulsar client or some missing/additional configuration.
   
   This is replicable in our CI environment running on ubuntu with docker.
   
   We run a local pulsar node from an available pulsar image 
apachepulsar/pulsar. We were using 2.5.0 but upgraded to 2.8.1 just to 
double-check this wasn't a version incompatibility (not unreasonable to think 
the 2.8.1 client would not work entirely with a 2.5.0 broker).
   
   We generate a self-signed cert using cfssl v1.6.1, and we're using RSA 2048.
   
   We use a Makefile to generate a key secret and admin/user keys
   
   ```
   PULSAR_DOCKER_IMAGE = "apachepulsar/pulsar:2.8.1"
   
   PULSAR = docker run --rm -v "$(CURDIR)/conf:/pulsar/conf" -v 
"$(CURDIR)/auth:/pulsar/auth" $(PULSAR_DOCKER_IMAGE) bin/pulsar
   
   tokens
$(PULSAR) tokens create-secret-key > auth/tokens/secret.key
$(PULSAR) tokens create --secret-key 
file:///pulsar/auth/tokens/secret.key --subject admin > auth/tokens/admin-token
$(PULSAR) tokens create --secret-key 
file:///pulsar/auth/tokens/secret.key --subject user > auth/tokens/user-token
   ```
   
   
   Client config:
   
   ```
   authParams=file:///pulsar/auth/admin-token
   authPlugin=org.apache.pulsar.client.impl.auth.AuthenticationToken
   brokerServiceUrl=pulsar://localhost:6650/
   tlsAllowInsecureConnection=false
   tlsEnableHostnameVerification=false
   tlsTrustCertsFilePath=/pulsar/auth/pulsar-ca/certs/ca.cert.pem
   webServiceUrl=http://localhost:8000/
   ```
   
   (we have a hostname mismatch due to localhost aliases being used i.e. if 
foo.bar.baz -> localhost)
   
   Our standalone pulsar configuration (generated broker settings with comments 
stripped)
   
   ```
   zookeeperServers=
   configurationStoreServers=
   brokerServicePort=6650
   webServicePort=8000
   bindAddress=0.0.0.0
   advertisedAddress=
   numIOThreads=
   numHttpServerThreads=
   clusterName=standalone
   failureDomainsEnabled=false
   zooKeeperSessionTimeoutMillis=3
   zooKeeperOperationTimeoutSeconds=30
   brokerShutdownTimeoutMs=6
   backlogQuotaCheckEnabled=true
   backlogQuotaCheckIntervalInSeconds=60
   backlogQuotaDefaultLimitGB=10
   ttlDurationDefaultInSeconds=0
   brokerDeleteInactiveTopicsEnabled=true
   brokerDeleteInactiveTopicsFrequencySeconds=60
   messageExpiryCheckIntervalInMinutes=5
   activeConsumerFailoverDelayTimeMillis=1000
   subscriptionExpirationTimeMinutes=0
   subscriptionRedeliveryTrackerEnabled=true
   subscriptionExpiryCheckIntervalInMinutes=5
   brokerDeduplicationEnabled=false
   brokerDeduplicationMaxNumberOfProducers=1
   brokerDeduplicationEntriesInterval=1000
   brokerDeduplicationProducerInactivityTimeoutMinutes=360
   defaultNumberOfNamespaceBundles=4
   clientLibraryVersionCheckEnabled=false
   statusFilePath=/usr/local/apache/htdocs
   maxUnackedMessagesPerConsumer=5
   maxUnackedMessagesPerSubscription=20
   maxUnackedMessagesPerBroker=0
   maxUnackedMessagesPerSubscriptionOnBrokerBlocked=0.16
   topicPublisherThrottlingTickTimeMillis=2
   brokerPublisherThrPottlingTickTimeMillis=50
   brokerPublisherThrottlingMaxMessageRate=0
   brokerPublisherThrottlingMaxByteRate=0
   dispatchThrottlingRatePerTopicInMsg=0
   dispatchThrottlingRatePerTopicInByte=0
   dispatchThrottlingRateRelativeToPublishRate=false
   dispatchThrottlingOnNonBacklogConsumerEnabled=true
   maxConcurrentLookupRequest=5
   maxConcurrentTopicLoadRequest=5000
   maxConcurrentNonPersistentMessagePerConnection=1000
   numWorkerThreadsForNonPersistentTopic=8
   enablePersistentTopics=true
   enableNonPersistentTopics=true
   maxProducersPerTopic=0
   maxConsumersPerTopic=0
   maxConsumersPerSubscription=0
   proxyRoles=
   authenticateOriginalAuthData=false
   authenticationEnabled=true
   
authenticationProviders=org.apache.pulsar.broker.authentication.AuthenticationProviderToken,org.apache.pulsar.broker.authentication.AuthenticationProviderTls
   tokenSecretKey=file:///pulsar/auth/tokens/secret.key
   authorizationEnabled=true
   
authorizationProvider=org.apache.pulsar.broker.authorization.PulsarAuthorizationProvider
   authorizationAllowWildcardsMatching=false
   superUserRoles=admin
   
brokerClientAuthenticationPlugin=org.apache.pulsar.client.impl.auth.AuthenticationToken
   brokerClientAuthenticationParameters=file:///pulsar/auth/tokens/admin-token
   athenzDomainNames=
   anonymousUserRole=anonymou

Re: [VOTE] PIP-117: Change Pulsar standalone defaults

[Haiting Jiang]

+1

Thanks,
Haiting

On 2021/12/23 05:35:03 Michael Marshall wrote:
> +1
> 
> - Michael
> 
> On Wed, Dec 22, 2021 at 6:18 PM Sijie Guo  wrote:
> >
> > +1
> >
> > On Tue, Dec 21, 2021 at 3:49 PM Matteo Merli  wrote:
> >
> > > This is the voting thread for PIP-117. It will stay open for at least 48h.
> > >
> > > https://github.com/apache/pulsar/issues/13302
> > >
> > > 
> > >
> > > ## Motivation
> > >
> > > Pulsar standalone is the "Pulsar in a box" version of a Pulsar cluster,
> > > where
> > > all the components are started within the context of a single JVM process.
> > >
> > > Users are using the standalone as a way to get quickly started with Pulsar
> > > or
> > > in all the cases where it makes sense to have a single node deployment.
> > >
> > > Right now, the standalone is starting by default with many components,
> > > several of
> > > which are quite complex, since they are designed to be deployed in a
> > > distributed
> > > fashion.
> > >
> > > ## Goal
> > >
> > > Simplify the components of Pulsar standalone to achieve:
> > >
> > >  1. Reduce complexity
> > >  2. Reduce startup time
> > >  3. Reduce memory and CPU footprint of running standalone
> > >
> > > ## Proposed changes
> > >
> > > The proposal here is to change some of the default implementations that 
> > > are
> > > used for the Pulsar standalone.
> > >
> > >  1. **Metadata Store implementation** -->
> > >   Change from ZooKeeper to RocksDB
> > >
> > >  2. **Pulsar functions package backend** -->
> > >   Change from using DistributedLog to using local filesystem, storing
> > > the
> > >   jars directly in the data folder instead of uploading them into BK.
> > >
> > >  3. **Pulsar functions state store implementation** -->
> > >   Change the state store to be backed by a MetadataStore based backed,
> > >   with the RocksDB implementation.
> > >
> > >  4. **Table Service** -->
> > >   Do not start BK table service by default
> > >
> > > ## Compatibility considerations
> > >
> > > In order to avoid compatibility issues where users have existing Pulsar
> > > standalone services that they want to upgrade without conflicts, we will
> > > follow the principle of keeping the old defaults where there is existing
> > > data on the disk.
> > >
> > > We will add a file, serving the purpose as a flag, in the 
> > > `data/standalone`
> > > directory, for example `new-2.10-defaults`.
> > >
> > > If the file is present, or if the data directory is completely missing, we
> > > will adopt the new set of default configuration settings.
> > >
> > > If the file is not there, we will continue to use existing defaults and we
> > > will
> > > not break the upgrade operation.
> > >
> > >
> > > --
> > > Matteo Merli
> > > 
> > >
> 

Re: [VOTE] PIP-123: Introduce Pulsar metadata CLI tool

[Haiting Jiang]

+1

Thanks,
Haiting

On 2021/12/23 05:38:14 Michael Marshall wrote:
> +1
> 
> - Michael
> 
> On Wed, Dec 22, 2021 at 6:18 PM Sijie Guo  wrote:
> >
> > +1
> >
> > On Tue, Dec 21, 2021 at 3:59 PM Matteo Merli  wrote:
> >
> > > This is the voting thread for PIP-123. It will stay open for at least 48h.
> > >
> > > https://github.com/apache/pulsar/issues/13346
> > >
> > >
> > > -
> > > ## Motivation
> > >
> > > For a very long time, we have included a CLI command to start the 
> > > ZooKeeper
> > > shell utility: `pulsar zookeeper-shell`, which is essentially a 
> > > repackaging
> > > of the ZooKeeper tool `zkCli.sh`.
> > >
> > > This is useful in some cases to either verify the content of metadata or
> > > to perform cleanup and modification tasks for which there is not an
> > > available
> > > option through the Pulsar REST APIs.
> > >
> > > While it's very useful, there are some drawbacks with the 
> > > `zookeeper-shell`
> > > as it is today:
> > >
> > >  1. This is only a ZooKeeper tool (obviously). Since we are adding more
> > > metadata backends, we should have a tool that works across all the
> > > implementations and presents a single consistent interface.
> > >
> > >  2. ZooKeeper shell is designed to be an interactive shell and it's not
> > > very
> > > good when trying to do non-interactive scriptable operations.
> > >
> > >  3. ZooKeeper is a bit clunky when using it and it requires the user to
> > > retype
> > > paths many times. The commands are not very intuitive or documented.
> > > It's not possible to update z-node with multi-lines content.
> > >
> > >  4. We cannot easily add functionality or improvements into ZooKeeper
> > > shell,
> > > since it belongs to a different project and the tool has been
> > > stagnating
> > > for many years.
> > >
> > >  5. In cases where the z-nodes content is binary (Protobuf) or compressed,
> > > there
> > > is no easy way to inspect the content from the ZooKeeper shell.
> > > Additionally, we can format and colorize JSON content to make it
> > > easier to
> > > read.
> > >
> > >  6. The paths used for metadata resources are also often using encodings
> > > that
> > > make it more difficult to construct on the shell tool.
> > >
> > > Part of what is described here is in the `pulsar-managed-ledger-admin` CLI
> > > tool,
> > > though that is a Python script that requires additional dependencies that
> > > are
> > > not typically installed, it only works with ZooKeeper, and it only targets
> > > accessing the managed ledger metadata.
> > >
> > > ## Goal
> > >
> > > Introduce a new Java CLI tool to access, inspect and modify metadata that
> > > solves
> > > all the issues described above.
> > >
> > > We would leave the `zookeeper-shell` command for now. In the future, once
> > > the
> > > new tool is proven, we can consider removing the `zookeeper-shell` 
> > > command.
> > >
> > >
> > > ## Proposed changes
> > >
> > > Add a new command:
> > > ```bash
> > > bin/pulsar metadata
> > > ```
> > >
> > > with several subcommands:
> > >
> > >
> > >  Get
> > >
> > > Examples:
> > > ```bash
> > > # General path get
> > > $ pulsar metadata get /my-path
> > >
> > >
> > > # Topic metadata
> > > $ pulsar metadata get topic my-tenant/my-namespace/my-topic
> > > {
> > >   # Managed ledger metadata
> > > }
> > >
> > > # Namespace get
> > > $ pulsar metadata get namespace my-tenant/my-namespace
> > > {
> > >   # Namespace metadata
> > > }
> > >
> > > $ pulsar metadata get ledger 12345
> > > {
> > >   # BK ledger metadata
> > > }
> > > ```
> > >
> > >  Delete
> > >
> > > Examples:
> > > ```bash
> > > # General path delete
> > > $ pulsar metadata delete /my-path
> > >
> > > # Topic metadata
> > > $ pulsar metadata delete topic my-tenant/my-namespace/my-topic
> > > ```
> > >
> > >  Scan
> > >
> > > Examples:
> > > ```bash
> > > $ pulsar metadata scan /my-path
> > > /my-path
> > > /my-path/1
> > > /my-path/2
> > > /my-path/3
> > > /my-path/3/1
> > >
> > > $ pulsar metadata scan --values /my-path
> > > /my-path
> > > {value}
> > >
> > > /my-path/1
> > > {value}
> > >
> > > /my-path/2
> > > {value}
> > > ```
> > >
> > >  Shell
> > >
> > > ```bash
> > > $ pulsar metadata shell
> > > > get topic my-tenant/my-namespace/my-topic
> > > {
> > >   # Managed ledger metadata
> > > }
> > >
> > > > delete topic my-tenant/my-namespace/my-topic
> > >
> > > > cd /my-path
> > > > ls
> > > 1
> > > 2
> > > 3
> > > > delete 1 # Delete keys with relative paths
> > >
> > > ```
> > >
> > >
> > > --
> > > Matteo Merli
> > > 
> > >
> 

[Vote] PIP 126: Support custom and pluggable consumer selector

[zhangao]

Hi Pulsar Community,
I would like to start a VOTE on the pluggable consumer selector (PIP 126). The 
issue for PIP 126 is here: https://github.com/apache/pulsar/issues/13473And the 
prototype implementation is here: https://github.com/apache/pulsar/pull/13470 
Please VOTE within 72 hours. Best Regards, zhangao

[ VOTE ] PIP-127: Support Consul metadata.

[mattison chao]

This is the voting thread for PIP-127,It will stay open for at least 48h.

the original issue here :

https://github.com/apache/pulsar/issues/13474


## Motivation

In many companies today, Consul is used in microservices to achieve related
business requirements.
If we can support Consul metadata, it will bring a better user experience.

After PIP-45, I think we can support consul metadata.

PIP-45:
https://github.com/apache/pulsar/wiki/PIP-45%3A-Pluggable-metadata-interface

## Goal

Support Consul metadata.

## API Changes

- Add ``ConsulMetadataStore``


Mattison

[GitHub] [pulsar-helm-chart] samuelzimmermanphillips opened a new issue #188: Unrecognized VM option 'PrintGCTimeStamps' - Unsupported Java 11 GC Flags causing init container fail

[GitBox]

samuelzimmermanphillips opened a new issue #188:
URL: https://github.com/apache/pulsar-helm-chart/issues/188


   Need to update the PULSAR_GC options in the default values to remove flags 
or add `-XX:+IgnoreUnrecognizedVMOptions`, otherwise init containers fail. 
   
   See here: 
https://confluence.atlassian.com/confkb/unrecognized-jvm-gc-options-when-using-java-11-1002472841.html


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [VOTE] PIP-123: Introduce Pulsar metadata CLI tool

[Christophe Bornet]

+1

Le mer. 22 déc. 2021 à 00:59, Matteo Merli  a écrit :

> This is the voting thread for PIP-123. It will stay open for at least 48h.
>
> https://github.com/apache/pulsar/issues/13346
>
>
> -
> ## Motivation
>
> For a very long time, we have included a CLI command to start the ZooKeeper
> shell utility: `pulsar zookeeper-shell`, which is essentially a repackaging
> of the ZooKeeper tool `zkCli.sh`.
>
> This is useful in some cases to either verify the content of metadata or
> to perform cleanup and modification tasks for which there is not an
> available
> option through the Pulsar REST APIs.
>
> While it's very useful, there are some drawbacks with the `zookeeper-shell`
> as it is today:
>
>  1. This is only a ZooKeeper tool (obviously). Since we are adding more
> metadata backends, we should have a tool that works across all the
> implementations and presents a single consistent interface.
>
>  2. ZooKeeper shell is designed to be an interactive shell and it's not
> very
> good when trying to do non-interactive scriptable operations.
>
>  3. ZooKeeper is a bit clunky when using it and it requires the user to
> retype
> paths many times. The commands are not very intuitive or documented.
> It's not possible to update z-node with multi-lines content.
>
>  4. We cannot easily add functionality or improvements into ZooKeeper
> shell,
> since it belongs to a different project and the tool has been
> stagnating
> for many years.
>
>  5. In cases where the z-nodes content is binary (Protobuf) or compressed,
> there
> is no easy way to inspect the content from the ZooKeeper shell.
> Additionally, we can format and colorize JSON content to make it
> easier to
> read.
>
>  6. The paths used for metadata resources are also often using encodings
> that
> make it more difficult to construct on the shell tool.
>
> Part of what is described here is in the `pulsar-managed-ledger-admin` CLI
> tool,
> though that is a Python script that requires additional dependencies that
> are
> not typically installed, it only works with ZooKeeper, and it only targets
> accessing the managed ledger metadata.
>
> ## Goal
>
> Introduce a new Java CLI tool to access, inspect and modify metadata that
> solves
> all the issues described above.
>
> We would leave the `zookeeper-shell` command for now. In the future, once
> the
> new tool is proven, we can consider removing the `zookeeper-shell` command.
>
>
> ## Proposed changes
>
> Add a new command:
> ```bash
> bin/pulsar metadata
> ```
>
> with several subcommands:
>
>
>  Get
>
> Examples:
> ```bash
> # General path get
> $ pulsar metadata get /my-path
>
>
> # Topic metadata
> $ pulsar metadata get topic my-tenant/my-namespace/my-topic
> {
>   # Managed ledger metadata
> }
>
> # Namespace get
> $ pulsar metadata get namespace my-tenant/my-namespace
> {
>   # Namespace metadata
> }
>
> $ pulsar metadata get ledger 12345
> {
>   # BK ledger metadata
> }
> ```
>
>  Delete
>
> Examples:
> ```bash
> # General path delete
> $ pulsar metadata delete /my-path
>
> # Topic metadata
> $ pulsar metadata delete topic my-tenant/my-namespace/my-topic
> ```
>
>  Scan
>
> Examples:
> ```bash
> $ pulsar metadata scan /my-path
> /my-path
> /my-path/1
> /my-path/2
> /my-path/3
> /my-path/3/1
>
> $ pulsar metadata scan --values /my-path
> /my-path
> {value}
>
> /my-path/1
> {value}
>
> /my-path/2
> {value}
> ```
>
>  Shell
>
> ```bash
> $ pulsar metadata shell
> > get topic my-tenant/my-namespace/my-topic
> {
>   # Managed ledger metadata
> }
>
> > delete topic my-tenant/my-namespace/my-topic
>
> > cd /my-path
> > ls
> 1
> 2
> 3
> > delete 1 # Delete keys with relative paths
>
> ```
>
>
> --
> Matteo Merli
> 
>

Re: [DISCUSS] Remove Grafana and Prometheus Dockerfiles; Remove DCOS example

[Michael Marshall]

Update: the PR [0] to remove the grafana docker image is now merged. I
still need reviews for the PR to remove the Prometheus docker image
[1]. I will follow up with a PR to remove the DCOS example.

Thanks,
Michael

[0] https://github.com/apache/pulsar/pull/13389
[1] https://github.com/apache/pulsar/pull/13387

On Mon, Dec 20, 2021 at 1:29 PM Michael Marshall  wrote:
>
> Hi Pulsar Community,
>
> I would like to clean up our main project's `docker/` directory. We
> have a couple of old Dockerfiles that either need to be updated or
> removed. My vote is to remove them.
>
> 1. Grafana: with every release, we build and upload a custom grafana
> docker image just to package dashboards. Grafana provides other
> mechanisms to load dashboards. I propose we remove the grafana image
> from our release process and then move our dashboard json files to a
> new top level directory named `grafana/`. [0]
>
> Our image is based on grafana/grafana:4.3.1. The current grafana
> release is grafana/grafana:8.3.3.
>
> 2. Prometheus: we have a prometheus Dockerfile that was initially
> merged as part of a DCOS example 4 years ago. We have never published
> this docker image as part of a release [1]. There is nothing pulsar
> specific in these files. [2]
>
> Our image is based on prom/prometheus:v1.8.2. The latest prometheus
> image prom/prometheus:v2.32.1.
>
> 3. Can we remove our DCOS examples in `deployment/dcos`? We haven't
> updated our DCOS example deployment spec in 3.5 years. The current
> spec relies on our custom grafana docker image and on a community
> member's custom build [3] of our prometheus-dcos docker image. I don't
> think our example deployment should rely on a community member's
> custom docker image. (I don't have a PR to remove this example yet.)
>
> Alternatively, we could update the dockerfiles and the DCOS example.
> However, the lack of activity in keeping these three project
> dependencies up to date indicates to me that we should remove them.
>
> Let me know what you think.
>
> Thanks,
> Michael
>
> [0] https://github.com/apache/pulsar/pull/13389
> [1] https://hub.docker.com/u/apachepulsar/
> [2] https://github.com/apache/pulsar/pull/13387
> [3] 
> https://github.com/apache/pulsar/blob/c62ca808fc8c5aed3bb96b99bf6ef0c8ed382e3f/deployment/dcos/PulsarGroups.json#L251

Re: [DISCUSS] Remove Grafana and Prometheus Dockerfiles; Remove DCOS example

[Matteo Merli]

+1

On Thu, Dec 23, 2021 at 9:53 AM Michael Marshall 
wrote:

> Update: the PR [0] to remove the grafana docker image is now merged. I
> still need reviews for the PR to remove the Prometheus docker image
> [1]. I will follow up with a PR to remove the DCOS example.
>
> Thanks,
> Michael
>
> [0] https://github.com/apache/pulsar/pull/13389
> [1] https://github.com/apache/pulsar/pull/13387
>
> On Mon, Dec 20, 2021 at 1:29 PM Michael Marshall 
> wrote:
> >
> > Hi Pulsar Community,
> >
> > I would like to clean up our main project's `docker/` directory. We
> > have a couple of old Dockerfiles that either need to be updated or
> > removed. My vote is to remove them.
> >
> > 1. Grafana: with every release, we build and upload a custom grafana
> > docker image just to package dashboards. Grafana provides other
> > mechanisms to load dashboards. I propose we remove the grafana image
> > from our release process and then move our dashboard json files to a
> > new top level directory named `grafana/`. [0]
> >
> > Our image is based on grafana/grafana:4.3.1. The current grafana
> > release is grafana/grafana:8.3.3.
> >
> > 2. Prometheus: we have a prometheus Dockerfile that was initially
> > merged as part of a DCOS example 4 years ago. We have never published
> > this docker image as part of a release [1]. There is nothing pulsar
> > specific in these files. [2]
> >
> > Our image is based on prom/prometheus:v1.8.2. The latest prometheus
> > image prom/prometheus:v2.32.1.
> >
> > 3. Can we remove our DCOS examples in `deployment/dcos`? We haven't
> > updated our DCOS example deployment spec in 3.5 years. The current
> > spec relies on our custom grafana docker image and on a community
> > member's custom build [3] of our prometheus-dcos docker image. I don't
> > think our example deployment should rely on a community member's
> > custom docker image. (I don't have a PR to remove this example yet.)
> >
> > Alternatively, we could update the dockerfiles and the DCOS example.
> > However, the lack of activity in keeping these three project
> > dependencies up to date indicates to me that we should remove them.
> >
> > Let me know what you think.
> >
> > Thanks,
> > Michael
> >
> > [0] https://github.com/apache/pulsar/pull/13389
> > [1] https://hub.docker.com/u/apachepulsar/
> > [2] https://github.com/apache/pulsar/pull/13387
> > [3]
> https://github.com/apache/pulsar/blob/c62ca808fc8c5aed3bb96b99bf6ef0c8ed382e3f/deployment/dcos/PulsarGroups.json#L251
>
-- 
--
Matteo Merli

Re: [DISCUSS] Proceeding with PIP-62 plan, before Apache Pulsar 2.10.0 is released

[Michael Marshall]

I think I misunderstood the current state of PIP 62. Once we clarify
the plan, it'd be helpful to update the wiki.

Thanks,
Michael



On Thu, Dec 23, 2021 at 2:43 AM Lari Hotari  wrote:
>
> > I believe we want to keep SQL until the code change lands in Trino.
> Because
> there are still users using this component.
>
> There have been multiple public dev@pulsar.apache.org discussions about
> PIP-62 which was initialized in April 2020.
> Those users using Pulsar SQL can keep on using Pulsar 2.8.x or 2.9.x until
> the feature is available in Trino. Isn't that a viable option?
>
> The Pulsar community is here to help with the work. What is the status of
> Trino work? Are there tasks that need help? Is there any ETA for the
> landing of code in Trino?
> Could we resolve this together?
>
> BR, Lari
>
> On Thu, Dec 23, 2021 at 2:39 AM Sijie Guo  wrote:
>
> > Sorry. When you say "we discussed", who are "we"? Is it DataStax?
> >
> > I believe we want to keep SQL until the code change lands in Trino. Because
> > there are still users using this component.
> >
> > - Sijie
> >
> > On Tue, Dec 21, 2021 at 11:34 PM Enrico Olivelli 
> > wrote:
> >
> > > Lari,
> > >
> > > Il giorno mer 22 dic 2021 alle ore 08:31 Lari Hotari  > >
> > > ha scritto:
> > >
> > > > Dear Pulsar community members,
> > > >
> > > > PIP-62[1], "PIP 62: Move connectors, adapters and Pulsar Presto to
> > > separate
> > > > repositories" was created in April 2020. The repositories for
> > > > pulsar-connectors, pulsar-adapters and pulsar-sql were created about a
> > > year
> > > > ago [2].
> > > >
> > > > I'd like to propose that we continue with the PIP-62 plan asap, before
> > > > Apache Pulsar 2.10.0 is released.
> > > >
> > > > I'm also suggesting that we drop Pulsar SQL from apache/pulsar without
> > > > waiting for the Trino Pulsar PR [3] being completed.
> > > >
> > > > I am volunteering to making the changes as per the PIP-62 plan.
> > > > When can we proceed with the plan? Do we need an explicit vote on the
> > > > mailing list about this?
> > > >
> > >
> > > We discussed this many times in the past year.
> > > I believe that there is no need to wait
> > >
> > > Enrico
> > >
> > >
> > >
> > > >
> > > > BR,
> > > >
> > > > Lari
> > > >
> > > > [1]
> > > >
> > > >
> > >
> > https://github.com/apache/pulsar/wiki/PIP-62%3A-Move-connectors%2C-adapters-and-Pulsar-Presto-to-separate-repositories
> > > > [2]
> > > >
> > > >
> > >
> > https://lists.apache.org/thread.html/r9e6ec742e2896da1f0ce7d4adc7cb84fc6db6dbf797732ccdd50fb86%40%3Cdev.pulsar.apache.org%3E
> > > > [3] https://github.com/trinodb/trino/pull/8020
> > > >
> > > > Other email threads:
> > > > * [Discuss] Don't include presto/trino in the normal Pulsar
> > distribution
> > > -
> > > > https://lists.apache.org/thread/jn96tct54mn0tvdot62vdslrvs38fm6d
> > > > * Updates on Presto connector for PIP-62 -
> > > > https://lists.apache.org/thread/f9n6sc2mrboq5sxhjbr7gvdl8vqp9fpk
> > > >
> > >
> >

Re: [DISCUSS] Remove Grafana and Prometheus Dockerfiles; Remove DCOS example

[Enrico Olivelli]

+1

Enrico

Il Gio 23 Dic 2021, 19:01 Matteo Merli  ha scritto:

> +1
>
> On Thu, Dec 23, 2021 at 9:53 AM Michael Marshall 
> wrote:
>
> > Update: the PR [0] to remove the grafana docker image is now merged. I
> > still need reviews for the PR to remove the Prometheus docker image
> > [1]. I will follow up with a PR to remove the DCOS example.
> >
> > Thanks,
> > Michael
> >
> > [0] https://github.com/apache/pulsar/pull/13389
> > [1] https://github.com/apache/pulsar/pull/13387
> >
> > On Mon, Dec 20, 2021 at 1:29 PM Michael Marshall 
> > wrote:
> > >
> > > Hi Pulsar Community,
> > >
> > > I would like to clean up our main project's `docker/` directory. We
> > > have a couple of old Dockerfiles that either need to be updated or
> > > removed. My vote is to remove them.
> > >
> > > 1. Grafana: with every release, we build and upload a custom grafana
> > > docker image just to package dashboards. Grafana provides other
> > > mechanisms to load dashboards. I propose we remove the grafana image
> > > from our release process and then move our dashboard json files to a
> > > new top level directory named `grafana/`. [0]
> > >
> > > Our image is based on grafana/grafana:4.3.1. The current grafana
> > > release is grafana/grafana:8.3.3.
> > >
> > > 2. Prometheus: we have a prometheus Dockerfile that was initially
> > > merged as part of a DCOS example 4 years ago. We have never published
> > > this docker image as part of a release [1]. There is nothing pulsar
> > > specific in these files. [2]
> > >
> > > Our image is based on prom/prometheus:v1.8.2. The latest prometheus
> > > image prom/prometheus:v2.32.1.
> > >
> > > 3. Can we remove our DCOS examples in `deployment/dcos`? We haven't
> > > updated our DCOS example deployment spec in 3.5 years. The current
> > > spec relies on our custom grafana docker image and on a community
> > > member's custom build [3] of our prometheus-dcos docker image. I don't
> > > think our example deployment should rely on a community member's
> > > custom docker image. (I don't have a PR to remove this example yet.)
> > >
> > > Alternatively, we could update the dockerfiles and the DCOS example.
> > > However, the lack of activity in keeping these three project
> > > dependencies up to date indicates to me that we should remove them.
> > >
> > > Let me know what you think.
> > >
> > > Thanks,
> > > Michael
> > >
> > > [0] https://github.com/apache/pulsar/pull/13389
> > > [1] https://hub.docker.com/u/apachepulsar/
> > > [2] https://github.com/apache/pulsar/pull/13387
> > > [3]
> >
> https://github.com/apache/pulsar/blob/c62ca808fc8c5aed3bb96b99bf6ef0c8ed382e3f/deployment/dcos/PulsarGroups.json#L251
> >
> --
> --
> Matteo Merli
> 
>

Docs site cache down?

[Patrick McFadin]

I've seen a lot of these errors on https://pulsar.apache.org/docs. Is that
ASF Infra? I can ping them if it's on them.

Error 503 Backend unavailable, connection timeout

Re: Docs site cache down?

[Dave Fisher]

It looks like a caching issue / missing redirect / httpd configuration. If you 
navigate to the docs from the main page it’s good while if try to hand write a 
url you and I get a 503.

Likely it should be an Infra JIRA issue.

It could make sense to examine the asf-site branch in Apache/pulsar repository.

Regards,
Dave

Sent from my iPhone

> On Dec 23, 2021, at 5:37 PM, Patrick McFadin  wrote:
> 
> I've seen a lot of these errors on https://pulsar.apache.org/docs. Is that
> ASF Infra? I can ping them if it's on them.
> 
> Error 503 Backend unavailable, connection timeout

[broker]loadBalancerMemoryResourceWeight config default value optimiz

[jiangxinwei]

https://github.com/apache/pulsar/pull/13464



Pasted below for quoting convenience. ---



Motivation

memory.percentUsage() value is depends on the gc trigger moment, this value
has a random affect on ThresholdShedder loadBalancer strategy. it is a
meaningless dimension

the usage data from one broker




solution

set loadBalancerMemoryResourceWeight=0.0



--
Avast 防毒软件已对此电子邮件执行病毒检查。
https://www.avast.com/antivirus

Re: Docs site cache down?

[Dave Fisher]

Infra is on the case

Sent from my iPhone

> On Dec 23, 2021, at 5:50 PM, Dave Fisher  wrote:
> 
> It looks like a caching issue / missing redirect / httpd configuration. If 
> you navigate to the docs from the main page it’s good while if try to hand 
> write a url you and I get a 503.
> 
> Likely it should be an Infra JIRA issue.
> 
> It could make sense to examine the asf-site branch in Apache/pulsar 
> repository.
> 
> Regards,
> Dave
> 
> Sent from my iPhone
> 
>> On Dec 23, 2021, at 5:37 PM, Patrick McFadin  wrote:
>> 
>> I've seen a lot of these errors on https://pulsar.apache.org/docs. Is that
>> ASF Infra? I can ping them if it's on them.
>> 
>> Error 503 Backend unavailable, connection timeout

Re: Docs site cache down?

[Dave Fisher]

All better.

Sent from my iPhone

> On Dec 23, 2021, at 6:03 PM, Dave Fisher  wrote:
> 
> Infra is on the case
> 
> Sent from my iPhone
> 
>> On Dec 23, 2021, at 5:50 PM, Dave Fisher  wrote:
>> 
>> It looks like a caching issue / missing redirect / httpd configuration. If 
>> you navigate to the docs from the main page it’s good while if try to hand 
>> write a url you and I get a 503.
>> 
>> Likely it should be an Infra JIRA issue.
>> 
>> It could make sense to examine the asf-site branch in Apache/pulsar 
>> repository.
>> 
>> Regards,
>> Dave
>> 
>> Sent from my iPhone
>> 
 On Dec 23, 2021, at 5:37 PM, Patrick McFadin  wrote:
>>> 
>>> I've seen a lot of these errors on https://pulsar.apache.org/docs. Is that
>>> ASF Infra? I can ping them if it's on them.
>>> 
>>> Error 503 Backend unavailable, connection timeout

Re: Docs site cache down?

[Guangning E]

>From my side that is working now

Thanks,
Guangning

Dave Fisher  于2021年12月24日周五 10:23写道：

> All better.
>
> Sent from my iPhone
>
> > On Dec 23, 2021, at 6:03 PM, Dave Fisher  wrote:
> >
> > Infra is on the case
> >
> > Sent from my iPhone
> >
> >> On Dec 23, 2021, at 5:50 PM, Dave Fisher  wrote:
> >>
> >> It looks like a caching issue / missing redirect / httpd
> configuration. If you navigate to the docs from the main page it’s good
> while if try to hand write a url you and I get a 503.
> >>
> >> Likely it should be an Infra JIRA issue.
> >>
> >> It could make sense to examine the asf-site branch in Apache/pulsar
> repository.
> >>
> >> Regards,
> >> Dave
> >>
> >> Sent from my iPhone
> >>
>  On Dec 23, 2021, at 5:37 PM, Patrick McFadin 
> wrote:
> >>>
> >>> I've seen a lot of these errors on https://pulsar.apache.org/docs.
> Is that
> >>> ASF Infra? I can ping them if it's on them.
> >>>
> >>> Error 503 Backend unavailable, connection timeout
>
>

Re: Docs site cache down?

[Huanli Meng]

It works properly from my side.

BR//Huanli Meng

> On Dec 24, 2021, at 11:01 AM, Guangning E  wrote:
> 
> From my side that is working now
> 
> Thanks,
> Guangning
> 
> Dave Fisher  于2021年12月24日周五 10:23写道：
> 
>> All better.
>> 
>> Sent from my iPhone
>> 
>>> On Dec 23, 2021, at 6:03 PM, Dave Fisher  wrote:
>>> 
>>> Infra is on the case
>>> 
>>> Sent from my iPhone
>>> 
 On Dec 23, 2021, at 5:50 PM, Dave Fisher  wrote:
 
 It looks like a caching issue / missing redirect / httpd
>> configuration. If you navigate to the docs from the main page it’s good
>> while if try to hand write a url you and I get a 503.
 
 Likely it should be an Infra JIRA issue.
 
 It could make sense to examine the asf-site branch in Apache/pulsar
>> repository.
 
 Regards,
 Dave
 
 Sent from my iPhone
 
>> On Dec 23, 2021, at 5:37 PM, Patrick McFadin 
>> wrote:
> 
> I've seen a lot of these errors on https://pulsar.apache.org/docs.
>> Is that
> ASF Infra? I can ping them if it's on them.
> 
> Error 503 Backend unavailable, connection timeout
>> 
>> 

Re: Docs site cache down?

[Patrick McFadin]

Yep. All good. Thanks Dave!

On Thu, Dec 23, 2021 at 7:06 PM Huanli Meng 
wrote:

> It works properly from my side.
>
> BR//Huanli Meng
>
> > On Dec 24, 2021, at 11:01 AM, Guangning E  wrote:
> >
> > From my side that is working now
> >
> > Thanks,
> > Guangning
> >
> > Dave Fisher  于2021年12月24日周五 10:23写道：
> >
> >> All better.
> >>
> >> Sent from my iPhone
> >>
> >>> On Dec 23, 2021, at 6:03 PM, Dave Fisher 
> wrote:
> >>>
> >>> Infra is on the case
> >>>
> >>> Sent from my iPhone
> >>>
>  On Dec 23, 2021, at 5:50 PM, Dave Fisher 
> wrote:
> 
>  It looks like a caching issue / missing redirect / httpd
> >> configuration. If you navigate to the docs from the main page it’s good
> >> while if try to hand write a url you and I get a 503.
> 
>  Likely it should be an Infra JIRA issue.
> 
>  It could make sense to examine the asf-site branch in Apache/pulsar
> >> repository.
> 
>  Regards,
>  Dave
> 
>  Sent from my iPhone
> 
> >> On Dec 23, 2021, at 5:37 PM, Patrick McFadin 
> >> wrote:
> >
> > I've seen a lot of these errors on https://pulsar.apache.org/docs.
> >> Is that
> > ASF Infra? I can ping them if it's on them.
> >
> > Error 503 Backend unavailable, connection timeout
> >>
> >>
>
>

[ANNOUNCE] Apache Pulsar 2.9.1 released

[Enrico Olivelli]

The Apache Pulsar team is proud to announce Apache Pulsar version 2.9.1.

Pulsar is a highly scalable, low latency messaging platform running on
commodity hardware. It provides simple pub-sub semantics over topics,
guaranteed at-least-once delivery of messages, automatic cursor management for
subscribers, and cross-datacenter replication.

For Pulsar release details and downloads, visit:

https://pulsar.apache.org/download

Release Notes are at:
http://pulsar.apache.org/release-notes

We would like to thank the contributors that made the release possible.

Regards,
The Pulsar Team

[GitHub] [pulsar-helm-chart] Technoboy- opened a new pull request #189: Bump to Pulsar 2.7.4

[GitBox]

Technoboy- opened a new pull request #189:
URL: https://github.com/apache/pulsar-helm-chart/pull/189


   Update the Helm Chart according to the release process
   https://github.com/apache/pulsar/wiki/Release-process#11-release-helm-chart


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [Vote] PIP 126: Support custom and pluggable consumer selector

[zhangao]

Hi Pulsar Community,   Please vote for this PIP.Best Regards,zhangao

[GitHub] [pulsar-helm-chart] eolivelli commented on a change in pull request #189: Bump to Pulsar 2.7.4

[GitBox]

eolivelli commented on a change in pull request #189:
URL: https://github.com/apache/pulsar-helm-chart/pull/189#discussion_r774908390



##
File path: charts/pulsar/Chart.yaml
##
@@ -18,10 +18,10 @@
 #
 
 apiVersion: v1
-appVersion: "2.7.2"
+appVersion: "2.7.4"
 description: Apache Pulsar Helm chart for Kubernetes
 name: pulsar
-version: 2.7.6
+version: 2.7.4

Review comment:
   you cannot set a value minor then 2.7.6




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [Vote] PIP 126: Support custom and pluggable consumer selector

[Enrico Olivelli]

zhangao,
I missed the discussion thread about this change.

did we discuss this somewhere ?
otherwise it is premature to start a VOTE

Enrico

Il giorno ven 24 dic 2021 alle ore 08:22 zhangao
 ha scritto:
>
> Hi Pulsar Community,   Please vote for this PIP.Best Regards,zhangao