Re: [DISCUSS] PIP-327 Support force topic loading for unrecoverable errors

[PengHui Li]

Hi Rajan,

I tried to test the case that you provided in the proposal.

- Produce messages to a topic
- Unload the topic 5 times to ensure we have some ledgers in the topic
- Delete one ledger by using the bookkeeper shell
- Unload the topic again
- Start to produce messages again, it works
- Start a consumer to consume messages from the earliest position, it get
stuck on the deleted ledger

I don't see the topic load issues. The topic loading works fine, and the
producer works fine.
But the proposal said it would resolve the topic load issue, can you
reproduce the topic load issue?

Regards,
Penghui



On Wed, Dec 20, 2023 at 3:28 AM Rajan Dhabalia  wrote:

> Hi,
>
> We have an issue to fail loading topics in unrecoverable situation and
> impacting topic availability::
> https://github.com/apache/pulsar/issues/21751
> This PIP addresses the issue and allows brokers to handle such situations
> and maintain the topic availability:
>
> PIP: https://github.com/apache/pulsar/pull/21752
>
> Thanks,
> Rajan
>

Re: [VOTE] PIP-323: Complete Backlog Quota Telemetry

[Asaf Mesika]

The vote is now closed.
The PIP  is approved, with 4 +1 binding votes, by Yubaio, Mattison, Penghui
and Guo.


On Mon, Dec 18, 2023 at 4:55 PM mattison chao 
wrote:

> +1(binding)
>
> Best,
> Mattison
>
> > On Dec 13, 2023, at 16:22, Asaf Mesika  wrote:
> >
> > Hi,
> >
> > I'm starting the vote for PIP-323, since it has been reviewed by several
> > people and all comments have been resolved.
> >
> > Reminder:
> >
> > PIP-323 is introduced to fill the gap of backlog quota telemetry. It
> allows
> > the user to know when a time-based backlog quota is about to exceed, and
> > how many times it exceeded. It also adds backlog quota check duration
> > metric allowing the user to configure the interval for that check based
> on
> > data. Once this is implemented, the user can finally create an alert to
> > know when a certain topic is about to exceed its defined backlog quota
> > limit, alert on it, and use topic stats Admin API to grab the
> subscription
> > name causing it.
> >
> > PIP link: https://github.com/apache/pulsar/pull/21709
> >
> >
> > Thanks,
> >
> > Asaf
>
>

Re: [VOTE] Release Apache Pulsar Helm Chart 3.1.0 based on 3.1.0-candidate-1

[PengHui Li]

+1 (binding)

Tested with Docker Desktop integrated with k8s v1.27.

- Deployed a cluster by using helm install pulsar
apache-pulsar-dist-dev/pulsar --set affinity.anti_affinity=false
- Tested produce and consume

Regards,
Penghui

On Wed, Dec 20, 2023 at 12:25 AM Lari Hotari  wrote:

> +1
>
> - Validated the release by installing to Docker Desktop integrated k8s
> v1.28.
>
> Followed validation instructions at
> https://github.com/apache/pulsar-helm-chart/blob/master/RELEASE.md#verify-the-release-candidate-by-the-pmc
> :
> - checked the packages are present in the right dist folder on svn
> - verified that all the sources have correct licenses
> - verified that release is signed with the right key
> - verified that checksums are valid for the release
>
> I did have an issue with the .rat-excludes file since rat reports some
> files without license headers and I wasn't able to exclude them after
> spending some time in editing the file.
> The files are under .github directory, mainly the issue templates. That
> should be fine for the release.
>
> -Lari
>
> On 2023/12/11 12:24:19 Lari Hotari wrote:
> > Hello Apache Pulsar Community,
> >
> > This is a call for the vote to release the Apache Pulsar Helm Chart
> version 3.1.0.
> >
> > The release candidate is available at:
> >
> https://dist.apache.org/repos/dist/dev/pulsar/helm-chart/3.1.0-candidate-1/
> >
> > pulsar-chart-3.1.0-source.tar.gz - is the "main source release".
> > pulsar-3.1.0.tgz - is the binary Helm Chart release.
> >
> > Public keys are available at: https://www.apache.org/dist/pulsar/KEYS
> >
> > For convenience "index.yaml" has been uploaded (though excluded from
> voting), so you can also run the below commands.
> >
> > helm repo add apache-pulsar-dist-dev
> https://dist.apache.org/repos/dist/dev/pulsar/helm-chart/3.1.0-candidate-1/
> > helm repo update
> > helm install pulsar apache-pulsar-dist-dev/pulsar
> >
> > pulsar-3.1.0.tgz.prov - is also uploaded for verifying Chart Integrity,
> though it is not strictly required for releasing the artifact based on ASF
> Guidelines.
> >
> > You can optionally verify this file using this helm plugin
> https://github.com/technosophos/helm-gpg, or by using helm --verify (
> https://helm.sh/docs/helm/helm_verify/).
> >
> > helm gpg verify pulsar-3.1.0.tgz
> >
> > The vote will be open for at least 72 hours.
> >
> > Only votes from PMC members are binding, but members of the community are
> > encouraged to test the release and vote with "(non-binding)".
> >
> > For license checks, the .rat-excludes files is included, so you can run
> the following to verify licenses (just update ):
> >
> > tar -xvf pulsar-chart-3.1.0-source.tar.gz
> > cd pulsar-chart-3.1.0
> > java -jar /apache-rat-0.15/apache-rat-0.15.jar . -E .rat-excludes
> >
> > Please note that the version number excludes the `-candidate-X` string,
> so it's now
> > simply 3.1.0. This will allow us to rename the artifact without modifying
> > the artifact checksums when we actually release it.
> >
> > Thanks,
> >
> > Lari Hotari
> >
>

Re: [DISCUSS] PIP-327 Support force topic loading for unrecoverable errors

[太上玄元道君]

In my understanding, the PIP is for some certain `extreme` conditions. Some
ledgers failing to recover is an event with a very low probability, and it
should be hard to reproduce(unless we delete some ledgers manually).

If we skip these failed-recover ledgers, message production should be able
to proceed smoothly.

But for message consumption, how can we deal with it?
1. Skip them: it will lead to data loss, even these ledgers just failed to
recover temporarily.
2. Not skip them: Consumers may cann't receive messages from brokers, the
consumption of messages cannot proceed normally, even these ledgers were
deleted and cannot recover.

So we must accurately determine whether these Ledgers are temporarily
unable to recover or will never be able to recover.
Maybe we need to persist the failed-recover number of times of the ledger
into MetadataStore, if the ledger recovers successfully, set it to 0, else,
+1.
And introduce a new configuration such as
`ledgerFailedToRecoverThreashold`,
if the ledger continues to fail-recover, and the number of times is
greater than `ledgerFailedToRecoverThreashold` , delete the ledger from
MetadataStore.

Thanks

PengHui Li  于2023年12月20日周三 16:32写道：

> Hi Rajan,
>
> I tried to test the case that you provided in the proposal.
>
> - Produce messages to a topic
> - Unload the topic 5 times to ensure we have some ledgers in the topic
> - Delete one ledger by using the bookkeeper shell
> - Unload the topic again
> - Start to produce messages again, it works
> - Start a consumer to consume messages from the earliest position, it get
> stuck on the deleted ledger
>
> I don't see the topic load issues. The topic loading works fine, and the
> producer works fine.
> But the proposal said it would resolve the topic load issue, can you
> reproduce the topic load issue?
>
> Regards,
> Penghui
>
>
>
> On Wed, Dec 20, 2023 at 3:28 AM Rajan Dhabalia 
> wrote:
>
> > Hi,
> >
> > We have an issue to fail loading topics in unrecoverable situation and
> > impacting topic availability::
> > https://github.com/apache/pulsar/issues/21751
> > This PIP addresses the issue and allows brokers to handle such situations
> > and maintain the topic availability:
> >
> > PIP: https://github.com/apache/pulsar/pull/21752
> >
> > Thanks,
> > Rajan
> >
>

Re: [DISCUSS] PIP-327 Support force topic loading for unrecoverable errors

[Rajan Dhabalia]

>  I don't see the topic load issues. The topic loading works fine, and
the producer works fine. But the proposal said it would resolve the topic
load issue, can you reproduce the topic load issue?

Yes, you tried different usecase and not the one which is mentioned in the
PIP. Deleted ledgers give specific error code that is handled by broker and
broker skips such non-recoverable ledgers. However, you can reproduce issue
#21751 when bookies are removed from the clusters without graceful
recovery, in that case brokers can not conclude such non-recoverable errors
which could have impacted multiple ledgers and topics, and it makes those
topics unavailable until there will be a manual cleanup of managed-ledger
metadata for each topic.

>> And introduce a new configuration such as
`ledgerFailedToRecoverThreashold`, if the ledger continues to fail-recover,.

No, let's not introduce such unnecessary complication as we already have
autoSkipNonRecoverableData flag to handle non-recoverable errors and one
doesn't want to take a bet on number of retries to skip non-recoverable
data but one needs a control when one is sure about actual data loss or
bookies are removed from the clusters and one really requires force
skipping such non-recoverable data using a flag that helps to forcefully
skip them.

Thanks,
Rajan

On Wed, Dec 20, 2023 at 1:17 AM 太上玄元道君  wrote:

> In my understanding, the PIP is for some certain `extreme` conditions. Some
> ledgers failing to recover is an event with a very low probability, and it
> should be hard to reproduce(unless we delete some ledgers manually).
>
> If we skip these failed-recover ledgers, message production should be able
> to proceed smoothly.
>
> But for message consumption, how can we deal with it?
> 1. Skip them: it will lead to data loss, even these ledgers just failed to
> recover temporarily.
> 2. Not skip them: Consumers may cann't receive messages from brokers, the
> consumption of messages cannot proceed normally, even these ledgers were
> deleted and cannot recover.
>
> So we must accurately determine whether these Ledgers are temporarily
> unable to recover or will never be able to recover.
> Maybe we need to persist the failed-recover number of times of the ledger
> into MetadataStore, if the ledger recovers successfully, set it to 0, else,
> +1.
> And introduce a new configuration such as
> `ledgerFailedToRecoverThreashold`,
> if the ledger continues to fail-recover, and the number of times is
> greater than `ledgerFailedToRecoverThreashold` , delete the ledger from
> MetadataStore.
>
> Thanks
>
> PengHui Li  于2023年12月20日周三 16:32写道：
>
> > Hi Rajan,
> >
> > I tried to test the case that you provided in the proposal.
> >
> > - Produce messages to a topic
> > - Unload the topic 5 times to ensure we have some ledgers in the topic
> > - Delete one ledger by using the bookkeeper shell
> > - Unload the topic again
> > - Start to produce messages again, it works
> > - Start a consumer to consume messages from the earliest position, it get
> > stuck on the deleted ledger
> >
> > I don't see the topic load issues. The topic loading works fine, and the
> > producer works fine.
> > But the proposal said it would resolve the topic load issue, can you
> > reproduce the topic load issue?
> >
> > Regards,
> > Penghui
> >
> >
> >
> > On Wed, Dec 20, 2023 at 3:28 AM Rajan Dhabalia 
> > wrote:
> >
> > > Hi,
> > >
> > > We have an issue to fail loading topics in unrecoverable situation and
> > > impacting topic availability::
> > > https://github.com/apache/pulsar/issues/21751
> > > This PIP addresses the issue and allows brokers to handle such
> situations
> > > and maintain the topic availability:
> > >
> > > PIP: https://github.com/apache/pulsar/pull/21752
> > >
> > > Thanks,
> > > Rajan
> > >
> >
>

Re: [Vote] PIP-223: Add metrics for all Rest Endpoints

[Tao Jiuming]

bump

On 2022/11/28 08:47:01 Jiuming Tao wrote:
> Dear Pulsar Community,
> 
> Please review and vote on this PIP.
> 
> PIP link: https://github.com/apache/pulsar/issues/18560
> 
> Discuss thread:
> https://lists.apache.org/thread/z74vcn0yolzzrcc4ftonm9j3nbk4pzxm
> 
> Thanks,
> Tao Jiuming
> 

Re: [Vote] PIP-223: Add metrics for all Rest Endpoints

[太上玄元道君]

Sorry, the PIP had approved, please ignore.

Tao Jiuming  于2023年12月21日周四 04:25写道：

>
> bump
>
> On 2022/11/28 08:47:01 Jiuming Tao wrote:
> > Dear Pulsar Community,
> >
> > Please review and vote on this PIP.
> >
> > PIP link: https://github.com/apache/pulsar/issues/18560
> >
> > Discuss thread:
> > https://lists.apache.org/thread/z74vcn0yolzzrcc4ftonm9j3nbk4pzxm
> >
> > Thanks,
> > Tao Jiuming
> >
>

RE: Re: [DISCUSS] PIP-324: Alpine Docker images

[David Christle]

Are we sure the move to Alpine is worth the extensive performance testing and 
the risk of issues? Sticking with a popular glibc image like Temurin, 
Ubuntu/Debian, or ubi-minimal (mentioned also in this discussion) seems like a 
better path to me, without the risk of glibc vs musl issues. Using Distroless 
seems like another good potential option, as it would achieve the same aims as 
the Alpine move, with less potential risk. 

The DNS issues seen with Alpine are worth paying strong attention to. Someone 
running a Pulsar deployment using the images could have a very difficult time 
debugging library/glibc vs musl/DNS issues, due to their low-level nature. A 
fix for the DNS issue only landed less than a year ago [1]. Unless we have a 
compelling reason for Alpine, it may be safer to wait for more adoption/testing 
before choosing it for the official Pulsar images.

The two main arguments in the PIP are:

- Using a smaller base image like Alpine can save space. The relative size of 
the JRE image for Alpine is about 45% smaller than the equivalent Ubuntu slim 
image.

- The Ubuntu image has a few tens of CVEs in it, as reported by an automated 
container CVE scan tool, compared to 0 in Alpine.


These seem reasonable, but the true magnitude of benefit is likely lower in 
practice. The pulsar-all images are 2.7GB in size, so saving 166MB on the base 
+ JRE install translates to just a 6% smaller image. Unless we expect other 
installed packages part of pulsar-all to gain additional space savings on 
Alpine, this difference seems very marginal in practice.

Security-wise, I took a cursory look at the CVEs, and many of them are in 
libraries that aren’t used in a Pulsar deployment/are difficult to envision a 
practical exploit scenario. Automated scanning tool results should be taken 
with a grain of salt - they generate a lot of alerts, and many public container 
images throw off these CVE alerts nowadays. The counterargument is that only a 
fraction of the libraries indicated are even loaded at runtime, only some 
fraction of those end up potentially being exploitable, and only a smaller 
fraction have no fix/workaround. This isn’t to say reducing the vulnerability 
surface by using an image with less cruft in it is not a worthwhile endeavor — 
I do think we should try to tackle it -- but I’m simply trying to be realistic 
about what our actual gains will be from switching to Alpine.

It’s also worth mentioning we’d be moving away from other large open-source big 
data projects in a way. Spark [2], Flink [3], Kafka [4], Elasticsearch [5], and 
Trino [6] are based on Temurin/Ubuntu/ubi. In my brief search, I didn’t find 
familiar names of tools in the big data ecosystem with official images based on 
Alpine.

Distroless would also remove almost everything from our base images, minimizing 
space, reducing the vulnerability surface, and by extension, reducing the CVE 
alerts from automated tooling. Apache Druid [7] has used Distroless for a while 
in their official images. We could achieve the same aims without any risk from 
musl/glibc, DNS quirks, or other hiccups that Alpine may have. 

Regards,
David


[1] https://gitlab.alpinelinux.org/alpine/tsc/-/issues/43#note_295556
[2] Apache Spark - Temurin - 
https://github.com/apache/spark-docker/tree/master/3.5.0
[3] Apache Flink - Temurin - 
https://github.com/apache/flink-docker/tree/master/1.18
[4] KIP-975: Docker Image for Apache Kafka - Temurin - 
https://cwiki.apache.org/confluence/display/KAFKA/KIP-975%3A+Docker+Image+for+Apache+Kafka
[5] Elasticsearch - Ubuntu & ubi-minimal - 
https://github.com/elastic/elasticsearch/blob/bdde29720a9e37224a90e5f186abbcbc73ff9351/distribution/docker/README.md
[6] Trino - ubi, after moving from Ubuntu - 
https://hub.docker.com/layers/trinodb/trino/435/images/sha256-9540a785c31c4ba9ad099ad99ae06ccd5ccca506e39b7d557effe1482309e05d
[7] Apache Druid - Distroless - 
https://github.com/apache/druid/blob/e373f6269251655f5be93ce895aee8dee8cc67dd/distribution/docker/Dockerfile#L4


On 2023/12/13 17:06:12 Matteo Merli wrote:
> I don't think the compatibility for downstream users is going to be a big
> problem:
>  1. Most users don't need to modify the Pulsar image in significant way
>  2. If they do, they won't be using the "latest" tag, but rather a specific
> version
>  3. Users who are dependent on the Ubuntu base image can stay on the 3.0
> LTS release branch for the entire LTS lifespan
> 
> I would avoid supporting 2 images at the same time because it would make it
> very hard to properly test them both.
> 
> 
> --
> Matteo Merli
> 
> 
> 
> On Tue, Dec 12, 2023 at 8:57 PM Zixuan Liu  wrote:
> 
> > +1.
> >
> > It is a good idea to use the Alpine image to run the Pulsar, as it is more
> > secure.
> >
> > However, switching images may affect downstream users, and I am wondering
> > if it is possible to provide multiple docker tags:
> >   - latest: using the Ubuntu image
> >   - alpine: using the Alpine image
> >
> > Thanks,
> > Z

[VOTE] Pulsar Release 2.11.3 Candidate 2

[Baodi Shi]

This is the second release candidate for Apache Pulsar, version 2.11.3.

It fixes the following issues:
https://github.com/apache/pulsar/pulls?q=is%3Apr+label%3Arelease%2F2.11.3+is%3Aclosed

*** Please download, test and vote on this release. This vote will stay
open for at least 72 hours ***

Note that we are voting upon the source (tag), binaries are provided for
convenience.

Source and binary files:
https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.11.3-candidate-2/

SHA-512 checksums:

521316ea9f01b54f0fb3981dc017d3529de4019360c57c38c72c1ecfa53030927b93608acd71d0eb58f3e7eb6b4a2583a94796462d577d7dca0ba935a2f68fcf
 ./apache-pulsar-2.11.3-bin.tar.gz

4510c16d6ec90847eb8dff0246bd09190f99bc10a30702ab5f521971b13b6cffe0f9d1de9637b85340154ee38764a39551fd871bd1132d7760fb3a7e931a20e3
 ./apache-pulsar-2.11.3-src.tar.gz


Maven staging repo:
https://repository.apache.org/content/repositories/orgapachepulsar-1258/

The tag to be voted upon:
v2.11.3-candidate-2 (c7ac62c

)
https://github.com/apache/pulsar/releases/tag/v2.11.3-candidate-2

Pulsar’s KEYS file containing PGP keys you use to sign the release:
https://downloads.apache.org/pulsar/KEYS

Docker images:
docker pull wudixiaobaozi/pulsar-all:2.11.3
docker pull wudixiaobaozi/pulsar:2.11.3

Please download the source package, and follow the README to build
and run the Pulsar standalone service.

Thanks,
Baodi Shi

Re: [VOTE] Release Apache Pulsar Helm Chart 3.1.0 based on 3.1.0-candidate-1

[Michael Marshall]

+1 (binding)

- verified signatures are valid on 2 artifacts
- verified checksums are correct on 2 artifacts
- verified `helm gpg verify pulsar-3.1.0.tgz`
- verified the licenses and notice with `java -jar
/apache-rat-0.15/apache-rat-0.15.jar . -E .rat-excludes`. I noticed
that Lari had trouble, so I'm not sure what I did differently. I
include the script's output at the end of this email.
- reviewed commit log since previous release

I am not able to test the helm chart, but that isn't strictly required
for release validation, so I am going to skip that for now, and we can
address any bugs discovered later.

Thanks for running the release, Lari.

- Michael

$  java -jar ~/apache-rat-0.15/apache-rat-0.15.jar . -E .rat-excludes
Ignored 18 lines in your exclusion files as comments or empty lines.

*
Summary
---
Generated at: 2023-12-21T00:10:16-06:00

Notes: 4
Binaries: 0
Archives: 0
Standards: 94

Apache Licensed: 94
Generated Documents: 0

JavaDocs are generated, thus a license header is optional.
Generated files do not require license headers.

0 Unknown Licenses

*
  Files with Apache License headers will be marked AL
  Binary files (which do not require any license headers) will be marked B
  Compressed archives will be marked A
  Notices, licenses etc. will be marked N
  AL./.asf.yaml
  AL./.rat-excludes
  N ./LICENSE
  N ./NOTICE
  AL./README.md
  AL./RELEASE.md
  AL./Vagrantfile
  AL./license_test.go
  AL./charts/pulsar/.helmignore
  AL./charts/pulsar/Chart.yaml
  N ./charts/pulsar/LICENSE
  N ./charts/pulsar/NOTICE
  AL./charts/pulsar/values.yaml
  AL./charts/pulsar/templates/_autorecovery.tpl
  AL./charts/pulsar/templates/_bookkeeper.tpl
  AL./charts/pulsar/templates/_broker.tpl
  AL./charts/pulsar/templates/_configurationstore.tpl
  AL./charts/pulsar/templates/_helpers.tpl
  AL./charts/pulsar/templates/_toolset.tpl
  AL./charts/pulsar/templates/_zookeeper.tpl
  AL./charts/pulsar/templates/autorecovery-configmap.yaml
  AL./charts/pulsar/templates/autorecovery-podmonitor.yaml
  AL./charts/pulsar/templates/autorecovery-rbac.yaml
  AL./charts/pulsar/templates/autorecovery-service.yaml
  AL./charts/pulsar/templates/autorecovery-statefulset.yaml
  AL./charts/pulsar/templates/bookkeeper-cluster-initialize.yaml
  AL./charts/pulsar/templates/bookkeeper-configmap.yaml
  AL./charts/pulsar/templates/bookkeeper-pdb.yaml
  AL./charts/pulsar/templates/bookkeeper-podmonitor.yaml
  AL./charts/pulsar/templates/bookkeeper-rbac.yaml
  AL./charts/pulsar/templates/bookkeeper-service.yaml
  AL./charts/pulsar/templates/bookkeeper-statefulset.yaml
  AL./charts/pulsar/templates/bookkeeper-storageclass.yaml
  AL./charts/pulsar/templates/broker-cluster-role-binding.yaml
  AL./charts/pulsar/templates/broker-configmap.yaml
  AL./charts/pulsar/templates/broker-hpa.yaml
  AL./charts/pulsar/templates/broker-pdb.yaml
  AL./charts/pulsar/templates/broker-podmonitor.yaml
  AL./charts/pulsar/templates/broker-rbac.yaml
  AL./charts/pulsar/templates/broker-service-account.yaml
  AL./charts/pulsar/templates/broker-service.yaml
  AL./charts/pulsar/templates/broker-statefulset.yaml
  AL./charts/pulsar/templates/dashboard-deployment.yaml
  AL./charts/pulsar/templates/dashboard-ingress.yaml
  AL./charts/pulsar/templates/dashboard-service.yaml
  AL./charts/pulsar/templates/function-worker-configmap.yaml
  AL./charts/pulsar/templates/keytool.yaml
  AL./charts/pulsar/templates/namespace.yaml
  AL./charts/pulsar/templates/proxy-configmap.yaml
  AL./charts/pulsar/templates/proxy-hpa.yaml
  AL./charts/pulsar/templates/proxy-ingress.yaml
  AL./charts/pulsar/templates/proxy-pdb.yaml
  AL./charts/pulsar/templates/proxy-podmonitor.yaml
  AL./charts/pulsar/templates/proxy-rbac.yaml
  AL./charts/pulsar/templates/proxy-service.yaml
  AL./charts/pulsar/templates/proxy-statefulset.yaml
  AL./charts/pulsar/templates/pulsar-cluster-initialize.yaml
  AL./charts/pulsar/templates/pulsar-manager-admin-secret.yaml
  AL./charts/pulsar/templates/pulsar-manager-configmap.yaml
  AL./charts/pulsar/templates/pulsar-manager-deployment.yaml
  AL./charts/pulsar/templates/pulsar-manager-ingress.yaml
  AL./charts/pulsar/templates/pulsar-manager-service.yaml
  AL./charts/pulsar/templates/tls-cert-internal-issuer.yaml
  AL./charts/pulsar/templates/tls-certs-internal.yaml
  AL./charts/pulsar/templates/toolset-configmap.yaml
  AL./charts/pulsar/templates/toolset-rbac.yaml
  AL./charts/pulsar/templates/toolset-service.yaml
  AL./charts/pulsar/templates/toolset-statefulset.yaml
  AL./charts/pulsar/templates/zookeeper-configmap.yaml
  AL./charts/pulsar/templates/zookeeper-pdb.yaml
  AL./charts/p

Re: [VOTE] Release Apache Pulsar Helm Chart 3.1.0 based on 3.1.0-candidate-1

[Lari Hotari]

Hello all,

The vote to release Apache Pulsar Helm Chart version 3.1.0 based on 
3.1.0-candidate-1 is now closed.

The vote PASSED with 3 binding "+1", 0 non-binding "+1" and 0 "-1" votes:

"+1" Binding votes:

  - PengHui Li
  - Lari Hotari
  - Michael Marshall

I'll continue with the release process and the release announcement will follow 
shortly.

Thanks,

Lari

On 2023/12/11 12:24:19 Lari Hotari wrote:
> Hello Apache Pulsar Community,
> 
> This is a call for the vote to release the Apache Pulsar Helm Chart version 
> 3.1.0.
> 
> The release candidate is available at:
> https://dist.apache.org/repos/dist/dev/pulsar/helm-chart/3.1.0-candidate-1/
> 
> pulsar-chart-3.1.0-source.tar.gz - is the "main source release".
> pulsar-3.1.0.tgz - is the binary Helm Chart release.
> 
> Public keys are available at: https://www.apache.org/dist/pulsar/KEYS
> 
> For convenience "index.yaml" has been uploaded (though excluded from voting), 
> so you can also run the below commands.
> 
> helm repo add apache-pulsar-dist-dev 
> https://dist.apache.org/repos/dist/dev/pulsar/helm-chart/3.1.0-candidate-1/
> helm repo update
> helm install pulsar apache-pulsar-dist-dev/pulsar
> 
> pulsar-3.1.0.tgz.prov - is also uploaded for verifying Chart Integrity, 
> though it is not strictly required for releasing the artifact based on ASF 
> Guidelines.
> 
> You can optionally verify this file using this helm plugin 
> https://github.com/technosophos/helm-gpg, or by using helm --verify 
> (https://helm.sh/docs/helm/helm_verify/).
> 
> helm gpg verify pulsar-3.1.0.tgz
> 
> The vote will be open for at least 72 hours.
> 
> Only votes from PMC members are binding, but members of the community are
> encouraged to test the release and vote with "(non-binding)".
> 
> For license checks, the .rat-excludes files is included, so you can run the 
> following to verify licenses (just update ):
> 
> tar -xvf pulsar-chart-3.1.0-source.tar.gz
> cd pulsar-chart-3.1.0
> java -jar /apache-rat-0.15/apache-rat-0.15.jar . -E .rat-excludes
> 
> Please note that the version number excludes the `-candidate-X` string, so 
> it's now
> simply 3.1.0. This will allow us to rename the artifact without modifying
> the artifact checksums when we actually release it.
> 
> Thanks,
> 
> Lari Hotari
>