Re: [DISCUSS] 2.10 & 2.11 EOL - pulsar.apache.org website shows that support has ended
Bumping this thread to the top. We need to find a resolution. -Lari On Sat, 20 Jan 2024 at 11:13, Lari Hotari wrote: > > Hi, > > Our website shows that "active support" and "security support" has ended on > 11 Jan 2024 for 2.11 and on 18 Apr 2023 for 2.10 . You can find this > information in our release policy page at > https://pulsar.apache.org/contribute/release-policy/#supported-versions . > > Does this mean that the Apache Pulsar PMC won't be driving more new releases > for branch-2.11 and branch-2.10 ? Are there exceptions? > Do we need to make a separate decision about 2.10 & 2.11 EOL ? > > -Lari > > On 2023/12/19 06:25:20 Michael Marshall wrote: > > Hi Pulsar Community, > > > > Do we consider the 2.10 release line EOL? If not, is there a committer > > that would like to volunteer to release 2.10.6? > > > > We briefly discussed keeping 2.10 alive in June [0], and that was > > followed by a 2.10.5 release in July. Given that we already have 2.11, > > 3.0, 3.1, and now a discussion on 3.2, it seems unsustainable to keep > > 2.10 going much longer. > > > > Thanks, > > Michael > > > > [0] https://lists.apache.org/thread/w4jzk27qhtosgsz7l9bmhf1t7o9mxjhp > >
[VOTE] DotPulsar Release 3.1.2-rc.1
Hi everyone, Please review and vote on the release candidate 1 for the version 3.1.2, as follows: [ ] +1, Approve the release [ ] -1, Do not approve the release (please provide specific comments) DotPulsar's KEYS file contains the PGP keys we used to sign this release: https://downloads.apache.org/pulsar/KEYS Please download these packages and review this release candidate: - Review release notes - Download the source package (verify shasum, and asc) and follow the README.md to build and run DotPulsar. The vote will be open for at least 72 hours. It is adopted by majority approval, with at least 3 PMC affirmative votes. Source file: https://dist.apache.org/repos/dist/dev/pulsar/pulsar-dotpulsar-3.1.2-rc.1/ Nuget package: https://www.nuget.org/packages/DotPulsar/3.1.2-rc.1 The tag to be voted upon: https://github.com/apache/pulsar-dotpulsar/tree/3.1.2-rc.1 SHA-512 checksums: cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e pulsar-dotpulsar-3.1.2-src.tar.gz
Re: [VOTE] DotPulsar Release 3.1.2-rc.1
+1 (binding) Tested on Windows 10 with .NET 8(.0.101). Best regards Daniel Blankensteiner David Jensen skrev den 2024-01-25 12:27: Hi everyone, Please review and vote on the release candidate 1 for the version 3.1.2, as follows: [ ] +1, Approve the release [ ] -1, Do not approve the release (please provide specific comments) DotPulsar's KEYS file contains the PGP keys we used to sign this release: https://downloads.apache.org/pulsar/KEYS Please download these packages and review this release candidate: - Review release notes - Download the source package (verify shasum, and asc) and follow the README.md to build and run DotPulsar. The vote will be open for at least 72 hours. It is adopted by majority approval, with at least 3 PMC affirmative votes. Source file: https://dist.apache.org/repos/dist/dev/pulsar/pulsar-dotpulsar-3.1.2-rc.1/ Nuget package: https://www.nuget.org/packages/DotPulsar/3.1.2-rc.1 The tag to be voted upon: https://github.com/apache/pulsar-dotpulsar/tree/3.1.2-rc.1 SHA-512 checksums: cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e pulsar-dotpulsar-3.1.2-src.tar.gz
Re: [VOTE] Release Apache Pulsar Helm Chart 3.2.0 based on 3.2.0-candidate-3
+1 (binding) - Checked the license - Verify the signature - Deploy pulsar cluster on local docker-desktop Regards Jiwei Guo (Tboy) On Thu, Jan 25, 2024 at 12:17 AM Lari Hotari wrote: > +1 (binding) > > -Lari > > On 2024/01/21 08:45:04 Lari Hotari wrote: > > Hello Apache Pulsar Community, > > > > This is a call for the vote to release the Apache Pulsar Helm Chart > version 3.2.0. > > > > Release notes for 3.2.0-candidate-3: > > > https://github.com/apache/pulsar-helm-chart/releases/tag/pulsar-3.2.0-candidate-3 > > > > The release candidate is available at: > > > https://dist.apache.org/repos/dist/dev/pulsar/helm-chart/3.2.0-candidate-3/ > > > > pulsar-chart-3.2.0-source.tar.gz - is the "main source release". > > pulsar-3.2.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 --force-update apache-pulsar-dist-dev > https://dist.apache.org/repos/dist/dev/pulsar/helm-chart/3.2.0-candidate-3/ > > helm repo update > > helm install pulsar apache-pulsar-dist-dev/pulsar --version 3.2.0 --set > affinity.anti_affinity=false > > > > pulsar-3.2.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 fetch --prov apache-pulsar-dist-dev/pulsar > > helm plugin install https://github.com/technosophos/helm-gpg > > helm gpg verify pulsar-3.2.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.2.0-source.tar.gz > > cd pulsar-chart-3.2.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.2.0. This will allow us to rename the artifact without modifying > > the artifact checksums when we actually release it. > > > > Thanks, > > Lari > > >
Re: [VOTE] Release Apache Pulsar Helm Chart 3.2.0 based on 3.2.0-candidate-3
Hello all, The vote to release Apache Pulsar Helm Chart version 3.2.0 based on 3.2.0-candidate-3 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 - Jiwei Guo I'll continue with the release process and the release announcement will follow shortly. Thanks, Lari On 2024/01/21 08:45:04 Lari Hotari wrote: > Hello Apache Pulsar Community, > > This is a call for the vote to release the Apache Pulsar Helm Chart version > 3.2.0. > > Release notes for 3.2.0-candidate-3: > https://github.com/apache/pulsar-helm-chart/releases/tag/pulsar-3.2.0-candidate-3 > > The release candidate is available at: > https://dist.apache.org/repos/dist/dev/pulsar/helm-chart/3.2.0-candidate-3/ > > pulsar-chart-3.2.0-source.tar.gz - is the "main source release". > pulsar-3.2.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 --force-update apache-pulsar-dist-dev > https://dist.apache.org/repos/dist/dev/pulsar/helm-chart/3.2.0-candidate-3/ > helm repo update > helm install pulsar apache-pulsar-dist-dev/pulsar --version 3.2.0 --set > affinity.anti_affinity=false > > pulsar-3.2.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 fetch --prov apache-pulsar-dist-dev/pulsar > helm plugin install https://github.com/technosophos/helm-gpg > helm gpg verify pulsar-3.2.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.2.0-source.tar.gz > cd pulsar-chart-3.2.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.2.0. This will allow us to rename the artifact without modifying > the artifact checksums when we actually release it. > > Thanks, > Lari >
[ANNOUNCE] Apache Pulsar Helm Chart version 3.2.0 Released
Dear community, The Apache Pulsar team is pleased to announce the release of the Apache Pulsar Helm Chart 3.2.0. The official source release, as well as the binary Helm Chart release, are available at https://downloads.apache.org/pulsar/helm-chart/3.2.0/. The helm chart index at https://pulsar.apache.org/charts/ has been updated and the release is also available directly via helm. Release Notes: https://github.com/apache/pulsar-helm-chart/releases/tag/pulsar-3.2.0 Docs: https://github.com/apache/pulsar-helm-chart#readme and https://pulsar.apache.org/docs/helm-overview ArtifactHub: https://artifacthub.io/packages/helm/apache/pulsar/3.2.0 Thanks to all the contributors who made this possible. Regards, The Apache Pulsar Team
Re: [DISCUSS] 2.10 & 2.11 EOL - pulsar.apache.org website shows that support has ended
Clarity around this would be useful as we just started the process of upgrading from 2.10.3 to 2.11.3 I know 3.0 now has LTS but I not hoping to have to do another update for a while https://pulsar.apache.org/blog/2023/05/02/announcing-apache-pulsar-3-0/ Frank On Thu, Jan 25, 2024 at 6:11 AM Lari Hotari wrote: > Bumping this thread to the top. We need to find a resolution. > > -Lari > > On Sat, 20 Jan 2024 at 11:13, Lari Hotari wrote: > > > > Hi, > > > > Our website shows that "active support" and "security support" has ended > on 11 Jan 2024 for 2.11 and on 18 Apr 2023 for 2.10 . You can find this > information in our release policy page at > > https://pulsar.apache.org/contribute/release-policy/#supported-versions > . > > > > Does this mean that the Apache Pulsar PMC won't be driving more new > releases for branch-2.11 and branch-2.10 ? Are there exceptions? > > Do we need to make a separate decision about 2.10 & 2.11 EOL ? > > > > -Lari > > > > On 2023/12/19 06:25:20 Michael Marshall wrote: > > > Hi Pulsar Community, > > > > > > Do we consider the 2.10 release line EOL? If not, is there a committer > > > that would like to volunteer to release 2.10.6? > > > > > > We briefly discussed keeping 2.10 alive in June [0], and that was > > > followed by a 2.10.5 release in July. Given that we already have 2.11, > > > 3.0, 3.1, and now a discussion on 3.2, it seems unsustainable to keep > > > 2.10 going much longer. > > > > > > Thanks, > > > Michael > > > > > > [0] https://lists.apache.org/thread/w4jzk27qhtosgsz7l9bmhf1t7o9mxjhp > > > >
Re: [DISCUSS] 2.10 & 2.11 EOL - pulsar.apache.org website shows that support has ended
On a related note, according to the release policy page (https://pulsar.apache.org/contribute/release-policy/#supported-versions), the 3.1 branch only has ~16 more days of support. I'm hoping that 3.2.0 gets the green light for release before then, because we really didn't get much of a support overlap between the 3.1 and 3.2 releases. Thanks, Alex -Original Message- From: Frank Kelly Sent: Thursday, January 25, 2024 10:44 AM To: dev@pulsar.apache.org Subject: '[External]'Re: [DISCUSS] 2.10 & 2.11 EOL - pulsar.apache.org website shows that support has ended [You don't often get email from fke...@cogitocorp.com.invalid. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Clarity around this would be useful as we just started the process of upgrading from 2.10.3 to 2.11.3 I know 3.0 now has LTS but I not hoping to have to do another update for a while https://pulsar.apache.org/blog/2023/05/02/announcing-apache-pulsar-3-0/ Frank On Thu, Jan 25, 2024 at 6:11 AM Lari Hotari wrote: > Bumping this thread to the top. We need to find a resolution. > > -Lari > > On Sat, 20 Jan 2024 at 11:13, Lari Hotari wrote: > > > > Hi, > > > > Our website shows that "active support" and "security support" has > > ended > on 11 Jan 2024 for 2.11 and on 18 Apr 2023 for 2.10 . You can find > this information in our release policy page at > > https://pulsar.apache.org/contribute/release-policy/#supported-versi > > ons > . > > > > Does this mean that the Apache Pulsar PMC won't be driving more new > releases for branch-2.11 and branch-2.10 ? Are there exceptions? > > Do we need to make a separate decision about 2.10 & 2.11 EOL ? > > > > -Lari > > > > On 2023/12/19 06:25:20 Michael Marshall wrote: > > > Hi Pulsar Community, > > > > > > Do we consider the 2.10 release line EOL? If not, is there a > > > committer that would like to volunteer to release 2.10.6? > > > > > > We briefly discussed keeping 2.10 alive in June [0], and that was > > > followed by a 2.10.5 release in July. Given that we already have > > > 2.11, 3.0, 3.1, and now a discussion on 3.2, it seems > > > unsustainable to keep > > > 2.10 going much longer. > > > > > > Thanks, > > > Michael > > > > > > [0] > > > https://lists.apache.org/thread/w4jzk27qhtosgsz7l9bmhf1t7o9mxjhp > > > >
Re: [VOTE] PIP-329: Strategy for maintaining the latest tag to Pulsar docker images
Thanks to everyone! Close this vote with 3 bindings +1s: - Jiwei Guo (Tboy) - Penghui - Yunze And 1 non-binding +1: - Zixuan Thanks, Zike Yang On Fri, Jan 19, 2024 at 11:05 AM Yunze Xu wrote: > > +1 (binding) > > Thanks, > Yunze > > On Wed, Jan 17, 2024 at 12:37 PM PengHui Li wrote: > > > > +1 (binding) > > > > Regards, > > Penghui > > > > On Wed, Jan 17, 2024 at 11:05 AM guo jiwei wrote: > > > > > +1 (binding) > > > > > > > > > Regards > > > Jiwei Guo (Tboy) > > > > > > > > > On Mon, Jan 15, 2024 at 5:50 PM Zixuan Liu wrote: > > > > > > > +1(non-binding) > > > > > > > > Thanks, > > > > Zixuan > > > > > > > > Zike Yang 于2024年1月15日周一 16:14写道： > > > > > > > > > Hi, all > > > > > > > > > > I'm starting the vote for PIP-329: Strategy for maintaining the latest > > > > > tag to Pulsar docker images > > > > > > > > > > PIP link: https://github.com/apache/pulsar/pull/21872 > > > > > > > > > > Thanks, > > > > > Zike Yang > > > > > > > > > > > >
Re: [VOTE] DotPulsar Release 3.1.2-rc.1
-1 binding The source tarball uploaded is zerobyte. https://dist.apache.org/repos/dist/dev/pulsar/pulsar-dotpulsar-3.1.2-rc.1/pulsar-dotpulsar-3.1.2-src.tar.gz Best, tison. Daniel Blankensteiner 于2024年1月25日周四 19:30写道： > > +1 (binding) > > Tested on Windows 10 with .NET 8(.0.101). > > Best regards > > Daniel Blankensteiner > > David Jensen skrev den 2024-01-25 12:27: > > Hi everyone, > > > > Please review and vote on the release candidate 1 for the version > > 3.1.2, as > > follows: > > > > [ ] +1, Approve the release > > [ ] -1, Do not approve the release (please provide specific comments) > > > > DotPulsar's KEYS file contains the PGP keys we used to sign this > > release: > > https://downloads.apache.org/pulsar/KEYS > > > > Please download these packages and review this release candidate: > > - Review release notes > > - Download the source package (verify shasum, and asc) and follow the > > README.md to build and run DotPulsar. > > > > The vote will be open for at least 72 hours. It is adopted by majority > > approval, with at least 3 PMC affirmative votes. > > > > Source file: > > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-dotpulsar-3.1.2-rc.1/ > > > > Nuget package: > > https://www.nuget.org/packages/DotPulsar/3.1.2-rc.1 > > > > The tag to be voted upon: > > https://github.com/apache/pulsar-dotpulsar/tree/3.1.2-rc.1 > > > > SHA-512 checksums: > > > > cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e > > pulsar-dotpulsar-3.1.2-src.tar.gz
[DISCUSS] PIP-188(BlueGreenClusterMigration) Remove redirectedClusterURI in Pulsar Client
Hi dev, I would like to discuss this change with the community. Motivation: By this BlueGreenClusterMigration PIP-188( https://github.com/apache/pulsar/pull/17962), `redirectedClusterURI` member var has been introduced in the pulsar client to hold the new cluster's endpoint. Accordingly, pulsar client also added a state of a map of LookupService to lookup the migrated clusters. If redirectedClusterURI is not null, then clients look up the mapped, redirectedClusterURI->LookupService, when clients connect to migrated brokers. Proposal: In fact, this logic can be simplified by directly updating the existing lookup service's service url. Then, we don't need to track the new lookup services in a separate map and remove `redirectedClusterURI`, either. Hers is the sample code for this proposal: https://github.com/heesung-sn/pulsar/pull/59/ Pros: - The removal of redirectedClusterURI and the lookup service map can simplify the client code - It works better with other logics: Bundle Transfer and AutoClusterFailover, as these features currently only use the original lookup service. Cons: - To consume backlog from the blue (old) cluster, new clients need to be created with the old service url(pointing to the old cluster) because the existing clients' lookup service will be already updated, pointing to the new cluster. However, I think this(requiring a new client with old service url, old cluster) makes sense because all of the existing pub/sub will anyway be reconnected to the new clusters as per the broker's close commands. So, to consume the backlog from the old cluster, new client applications need to start with the old service url anyway. Example: https://github.com/heesung-sn/pulsar/pull/59/files#diff-3c745333eaeae9e8a87e92495fbf97b7c952c034b8c18ca92156f07cd5b1f5afR308-R312 Thanks, Heesung
Re: [VOTE] Pulsar Client Go Release 0.12.0 Candidate 3
+1 (binding) - Verified checksum and signatures - Built from source - Verified perf tool against a local 3.1.2 standalone - Verified produce and consume via OAuth2 authentication against StreamNative cloud Thanks, Yunze On Wed, Jan 24, 2024 at 8:47 PM PengHui Li wrote: > > +1 (binding) > > - Build from source > - Run tests on 3.1.2 > - Run tests on 3.0.2 > > Regards, > Penghui > > On Wed, Jan 24, 2024 at 2:59 PM Zike Yang wrote: > > > Hi everyone, > > Please review and vote on the release candidate #3 for the version > > 0.12.0, as follows: > > [ ] +1, Approve the release > > [ ] -1, Do not approve the release (please provide specific comments) > > > > This is the third release candidate for Apache Pulsar Go client, > > version 0.12.0. > > > > The release note/changelog for Go client 0.12.0: > > https://github.com/apache/pulsar-client-go/pull/1153/files > > > > Pulsar Client Go's KEYS file contains PGP keys we used to sign this > > release: > > https://downloads.apache.org/pulsar/KEYS > > > > Please download these packages and review this release candidate: > > - Review release notes: > > https://github.com/apache/pulsar-client-go/pull/1153 > > - Download the source package (verify shasum, and asc) and follow the > > README.md to build and run the pulsar-client-go. > > > > The vote will be open for at least 72 hours. It is adopted by majority > > approval, with at least 3 PMC affirmative votes. > > > > Source file: > > > > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-go-0.12.0-candidate-3/ > > > > The tag to be voted upon: > > v0.12.0-candidate-3 > > https://github.com/apache/pulsar-client-go/tree/v0.12.0-candidate-3 > > > > SHA-512 checksums: > > > > 66c37c4439549a02d7e3d21ecc02c4a2f44bad2232fbf15fb04c42f02fc4caad758b7a1b1663d0df47414af99daa4e3a19d33c29c0decbc43ac4d17e46a126bc > > apache-pulsar-client-go-0.12.0-src.tar.gz > >
Re: [DISCUSS] PIP-188(BlueGreenClusterMigration) Remove redirectedClusterURI in Pulsar Client
This might not work because same PulsarClient can be used to create multiple topics and producer/consumer and migration state can be different per topic and even for produce/consumer (of same topic) so, changing service url will not work for blue-green migration redirection for all topics served by that PulsarClient. Sent from my iPhone > On Jan 25, 2024, at 6:57 PM, Heesung Sohn wrote: > > Hi dev, > > I would like to discuss this change with the community. > > Motivation: > By this BlueGreenClusterMigration PIP-188( > https://github.com/apache/pulsar/pull/17962), `redirectedClusterURI` member > var has been introduced in the pulsar client to hold the new cluster's > endpoint. Accordingly, pulsar client also added a state of a map of > LookupService to lookup the migrated clusters. If redirectedClusterURI is > not null, then clients look up the mapped, > redirectedClusterURI->LookupService, when clients connect to migrated > brokers. > > Proposal: > In fact, this logic can be simplified by directly updating the > existing lookup service's service url. Then, we don't need to track the new > lookup services in a separate map and remove `redirectedClusterURI`, > either. > > Hers is the sample code for this proposal: > https://github.com/heesung-sn/pulsar/pull/59/ > > Pros: > - The removal of redirectedClusterURI and the lookup service map can > simplify the client code > - It works better with other logics: Bundle Transfer and > AutoClusterFailover, as these features currently only use the original > lookup service. > > Cons: > - To consume backlog from the blue (old) cluster, new clients need to be > created with the old service url(pointing to the old cluster) because the > existing clients' lookup service will be already updated, pointing to the > new cluster. > > However, I think this(requiring a new client with old service url, old > cluster) makes sense because all of the existing pub/sub will anyway be > reconnected to the new clusters as per the broker's close commands. So, to > consume the backlog from the old cluster, new client applications need to > start with the old service url anyway. > > Example: > https://github.com/heesung-sn/pulsar/pull/59/files#diff-3c745333eaeae9e8a87e92495fbf97b7c952c034b8c18ca92156f07cd5b1f5afR308-R312 > > Thanks, > Heesung
Re: [VOTE] Pulsar Client Go Release 0.12.0 Candidate 3
+1 (binding) - Build from source - Run Pub & Sub with the pulsar cluster(branch-master) Thanks Yubiao Feng On Wed, Jan 24, 2024 at 2:58 PM Zike Yang wrote: > Hi everyone, > Please review and vote on the release candidate #3 for the version > 0.12.0, as follows: > [ ] +1, Approve the release > [ ] -1, Do not approve the release (please provide specific comments) > > This is the third release candidate for Apache Pulsar Go client, > version 0.12.0. > > The release note/changelog for Go client 0.12.0: > https://github.com/apache/pulsar-client-go/pull/1153/files > > Pulsar Client Go's KEYS file contains PGP keys we used to sign this > release: > https://downloads.apache.org/pulsar/KEYS > > Please download these packages and review this release candidate: > - Review release notes: > https://github.com/apache/pulsar-client-go/pull/1153 > - Download the source package (verify shasum, and asc) and follow the > README.md to build and run the pulsar-client-go. > > The vote will be open for at least 72 hours. It is adopted by majority > approval, with at least 3 PMC affirmative votes. > > Source file: > > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-go-0.12.0-candidate-3/ > > The tag to be voted upon: > v0.12.0-candidate-3 > https://github.com/apache/pulsar-client-go/tree/v0.12.0-candidate-3 > > SHA-512 checksums: > > 66c37c4439549a02d7e3d21ecc02c4a2f44bad2232fbf15fb04c42f02fc4caad758b7a1b1663d0df47414af99daa4e3a19d33c29c0decbc43ac4d17e46a126bc > apache-pulsar-client-go-0.12.0-src.tar.gz >
Re: [DISCUSS] PIP-188(BlueGreenClusterMigration) Remove redirectedClusterURI in Pulsar Client
> This might not work because same PulsarClient can be used to create multiple topics and producer/consumer and migration state can be different per topic and even for produce/consumer (of same topic) so, changing service url will not work for blue-green migration redirection for all topics served by that PulsarClient. Good point on this topic (and producer and consumer) level migration requirement. I was under the impression that the migration happens for all topics from the old to the new cluster. For this requirement, I think we should keep redirectedClusterURI in HandlerState. Thanks for this quick response. Heesung On Thu, Jan 25, 2024 at 10:05 PM Rajan Dhabalia wrote: > This might not work because same PulsarClient can be used to create > multiple topics and producer/consumer and migration state can be different > per topic and even for produce/consumer (of same topic) so, changing > service url will not work for blue-green migration redirection for all > topics served by that PulsarClient. > > Sent from my iPhone > > > On Jan 25, 2024, at 6:57 PM, Heesung Sohn wrote: > > > > Hi dev, > > > > I would like to discuss this change with the community. > > > > Motivation: > > By this BlueGreenClusterMigration PIP-188( > > https://github.com/apache/pulsar/pull/17962), `redirectedClusterURI` > member > > var has been introduced in the pulsar client to hold the new cluster's > > endpoint. Accordingly, pulsar client also added a state of a map of > > LookupService to lookup the migrated clusters. If redirectedClusterURI is > > not null, then clients look up the mapped, > > redirectedClusterURI->LookupService, when clients connect to migrated > > brokers. > > > > Proposal: > > In fact, this logic can be simplified by directly updating the > > existing lookup service's service url. Then, we don't need to track the > new > > lookup services in a separate map and remove `redirectedClusterURI`, > > either. > > > > Hers is the sample code for this proposal: > > https://github.com/heesung-sn/pulsar/pull/59/ > > > > Pros: > > - The removal of redirectedClusterURI and the lookup service map can > > simplify the client code > > - It works better with other logics: Bundle Transfer and > > AutoClusterFailover, as these features currently only use the original > > lookup service. > > > > Cons: > > - To consume backlog from the blue (old) cluster, new clients need to be > > created with the old service url(pointing to the old cluster) because the > > existing clients' lookup service will be already updated, pointing to the > > new cluster. > > > > However, I think this(requiring a new client with old service url, old > > cluster) makes sense because all of the existing pub/sub will anyway be > > reconnected to the new clusters as per the broker's close commands. So, > to > > consume the backlog from the old cluster, new client applications need to > > start with the old service url anyway. > > > > Example: > > > https://github.com/heesung-sn/pulsar/pull/59/files#diff-3c745333eaeae9e8a87e92495fbf97b7c952c034b8c18ca92156f07cd5b1f5afR308-R312 > > > > Thanks, > > Heesung >
Re: [DISCUSS] PIP-188(BlueGreenClusterMigration) Remove redirectedClusterURI in Pulsar Client
I am sorry, but the current implementation of blue-green migration is for all topics (producers and customers), not topic-specific. Could you correct me if I am wrong here? So, for the current requirement(all topics migration), can't we just update the original lookup service for that client because all of the topics (of consumers and producers) will eventually migrate to the new cluster? Having said this, having redirectedClusterURI in HandlerState appears to be futuristic. Heesung On Thu, Jan 25, 2024 at 10:36 PM Heesung Sohn wrote: > > This might not work because same PulsarClient can be used to create > multiple topics and producer/consumer and migration state can be different > per topic and even for produce/consumer (of same topic) so, changing > service url will not work for blue-green migration redirection for all > topics served by that PulsarClient. > > Good point on this topic (and producer and consumer) level migration > requirement. I was under the impression that the migration happens for all > topics from the old to the new cluster. > > For this requirement, I think we should keep redirectedClusterURI in > HandlerState. > > Thanks for this quick response. > Heesung > > > On Thu, Jan 25, 2024 at 10:05 PM Rajan Dhabalia > wrote: > >> This might not work because same PulsarClient can be used to create >> multiple topics and producer/consumer and migration state can be different >> per topic and even for produce/consumer (of same topic) so, changing >> service url will not work for blue-green migration redirection for all >> topics served by that PulsarClient. >> >> Sent from my iPhone >> >> > On Jan 25, 2024, at 6:57 PM, Heesung Sohn wrote: >> > >> > Hi dev, >> > >> > I would like to discuss this change with the community. >> > >> > Motivation: >> > By this BlueGreenClusterMigration PIP-188( >> > https://github.com/apache/pulsar/pull/17962), `redirectedClusterURI` >> member >> > var has been introduced in the pulsar client to hold the new cluster's >> > endpoint. Accordingly, pulsar client also added a state of a map of >> > LookupService to lookup the migrated clusters. If redirectedClusterURI >> is >> > not null, then clients look up the mapped, >> > redirectedClusterURI->LookupService, when clients connect to migrated >> > brokers. >> > >> > Proposal: >> > In fact, this logic can be simplified by directly updating the >> > existing lookup service's service url. Then, we don't need to track the >> new >> > lookup services in a separate map and remove `redirectedClusterURI`, >> > either. >> > >> > Hers is the sample code for this proposal: >> > https://github.com/heesung-sn/pulsar/pull/59/ >> > >> > Pros: >> > - The removal of redirectedClusterURI and the lookup service map can >> > simplify the client code >> > - It works better with other logics: Bundle Transfer and >> > AutoClusterFailover, as these features currently only use the original >> > lookup service. >> > >> > Cons: >> > - To consume backlog from the blue (old) cluster, new clients need to be >> > created with the old service url(pointing to the old cluster) because >> the >> > existing clients' lookup service will be already updated, pointing to >> the >> > new cluster. >> > >> > However, I think this(requiring a new client with old service url, old >> > cluster) makes sense because all of the existing pub/sub will anyway be >> > reconnected to the new clusters as per the broker's close commands. So, >> to >> > consume the backlog from the old cluster, new client applications need >> to >> > start with the old service url anyway. >> > >> > Example: >> > >> https://github.com/heesung-sn/pulsar/pull/59/files#diff-3c745333eaeae9e8a87e92495fbf97b7c952c034b8c18ca92156f07cd5b1f5afR308-R312 >> > >> > Thanks, >> > Heesung >> >
Re: [VOTE] DotPulsar Release 3.1.2-rc.1
release aborted: Will reupload On 2024/01/25 11:27:08 David Jensen wrote: > Hi everyone, > > Please review and vote on the release candidate 1 for the version 3.1.2, as > follows: > > [ ] +1, Approve the release > [ ] -1, Do not approve the release (please provide specific comments) > > DotPulsar's KEYS file contains the PGP keys we used to sign this release: > https://downloads.apache.org/pulsar/KEYS > > Please download these packages and review this release candidate: > - Review release notes > - Download the source package (verify shasum, and asc) and follow the > README.md to build and run DotPulsar. > > The vote will be open for at least 72 hours. It is adopted by majority > approval, with at least 3 PMC affirmative votes. > > Source file: > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-dotpulsar-3.1.2-rc.1/ > > Nuget package: > https://www.nuget.org/packages/DotPulsar/3.1.2-rc.1 > > The tag to be voted upon: > https://github.com/apache/pulsar-dotpulsar/tree/3.1.2-rc.1 > > SHA-512 checksums: > > cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e > pulsar-dotpulsar-3.1.2-src.tar.gz >
