Re: [discuss] prometheus metrics doesn't satisfy with OpenMetrics format
Sorry for missing the information. Before I upgrade the prom client, pulsar metrics is ``` - pulsar_connection_closed_total_count - pulsar_connection_created_total_count - pulsar_source_received_total_1min - system_exceptions_total_1min ``` After ``` - pulsar_connection_closed_total_count_total - pulsar_connection_created_total_count_total - pulsar_source_received_total_1min_total - system_exceptions_total_1min_total ``` Prometheus client adds a `_total` suffix in pulsar metrics, because they require all counters to have `_total` suffix, if your metric name is not ended with `_total`, they will add it. I believe that the right name which satisfies `OpenMetrics` should be ``` - pulsar_connection_closed_total - pulsar_connection_created_total - pulsar_source_received_1min_total - system_exceptions_1min_total ``` Summary, upgrade prometheus client introduces breaking change for these metrics names which did not end with `_total`. PS: If you let the prometheus client add `_total` in the previous version, these metrics are not impacted. Enrico Olivelli 于2022年2月8日周二 15:54写道： > What happens when you upgrade the Prometheus client ? > > Can you share some examples of "before" and "after" ? > My understanding is that you posted how it looks like "after" the upgrade > > Thanks for working on this > > Enrico > > Il giorno mar 8 feb 2022 alle ore 08:21 ZhangJian He > ha scritto: > > > > Before, I am working on bumping Prometheus client to 0.12.0, but they > > introduce a breaking change, > > https://github.com/prometheus/client_java/pull/615, adopt the > `OpenMetrics > > format`, which acquired all counters have `_total` suffix, > > > > but our metrics now have these metrics, there are not satisfied with the > > OpenMetrics format, for example: > > > > - pulsar_connection_closed_total_count > > > > - pulsar_connection_created_total_count > > > > - pulsar_source_received_total_1min > > > > - system_exceptions_total_1min > > > > > > I want to discuss, Should we adapt the `OpenMetrics format`? > > > > If we want to be compatible with Open Metrics, I suggest adding metrics > > named `_total` in a release version like 2.10.0, and removing the origin > > metric in the next release like 2.11.0. >
Re: [VOTE] Pulsar Release 2.9.2 Candidate 2
+1 (binding) Verified the following context. 1. Checked the checksum and licenses 2. Build from the source code successfully 3. Start standalone and run pulsar-perf with produce and consume 4. Checked the Pulsar function and stateful functions 5. Run Pulsar with KOP and publish and consume successfully with Kafka 3.1.0 client Best, Hang PengHui Li 于2022年2月7日周一 18:01写道： > > +1 (binding) > > 1. Checked the signature > 2. Build from the source successfully > 3. Start standalone > 4. Publish and consume successfully > 5. Cassandra connect works well > 6. Checked state function > > And passed our internal integration tests. > > Regards, > Penghui > > On Mon, Feb 7, 2022 at 4:37 PM PengHui Li wrote: > > > It's not a regression in 2.9.2, we should not block the 2.9.2 release. > > Instead, we can have the fix in 2.9.3. > > > > Penghui > > > > On Thu, Feb 3, 2022 at 8:42 PM Nicolò Boschi wrote: > > > >> Hi Ran, thanks for driving the release. > >> > >> I haven't tested the rc yet but I firmly believe we should include this > >> pull [1] which fixes a regression introduced in Pulsar 2.9.0 > >> > >> [1] https://github.com/apache/pulsar/pull/14097 > >> > >> > >> > >> Il giorno mer 2 feb 2022 alle ore 08:34 Enrico Olivelli < > >> eolive...@gmail.com> > >> ha scritto: > >> > >> > (sorry for the late reply, I am still testing, I had some other > >> > priorities). > >> > > >> > I hope that the community will test this RC and report back > >> > > >> > > >> > Enrico > >> > > >> > Il giorno mar 25 gen 2022 alle ore 15:07 Ran Gao ha > >> > scritto: > >> > > > >> > > Sorry, the 2.9.2 release candidate-1 has a wrong sign certificate. > >> > > > >> > > This is the second release candidate for Apache Pulsar, version 2.9.2. > >> > > > >> > > *** 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.9.2-candidate-2/ > >> > > > >> > > SHA-512 checksums: > >> > > > >> > > > >> > > >> 563f65582c5307b4ef1e0322958ed19d7c181fb8bb8d7b8cab06ab0a6adb5520f7d18b6f97960b93c3318815529a8b8721e00e9cc9484532a2e5ed3221450094 > >> > > ./apache-pulsar-2.9.2-bin.tar.gz > >> > > > >> > > >> 60d1049611b938b0ddc769132124d43820728afc8a06813a5ec9efc095c5497c59d9bbcaaf7df5b0c0e97e051d66f59c1f8ee08885d05ca2c635773e0283770a > >> > > ./apache-pulsar-2.9.2-src.tar.gz > >> > > > >> > > Maven staging repo: > >> > > > >> https://repository.apache.org/content/repositories/orgapachepulsar-1136 > >> > > > >> > > The tag to be voted upon: > >> > > v2.9.2-candidate-2 (8a5d2253b888b3b865a2aedf635d672821c7) > >> > > https://github.com/apache/pulsar/releases/tag/v2.9.2-candidate-2 > >> > > > >> > > Pulsar's KEYS file containing PGP keys we use to sign the release: > >> > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS > >> > > > >> > > Please download the source package, and follow the README to build > >> > > and run the Pulsar standalone service. > >> > > >> > >> > >> -- > >> Nicolò Boschi > >> > >
[GitHub] [pulsar-client-node] massakam commented on issue #191: Segault with pulsar 2.9.1 and node 16.13.2
massakam commented on issue #191: URL: https://github.com/apache/pulsar-client-node/issues/191#issuecomment-1032358001 @Matt-Esch Could you provide the code to reproduce this issue? And how often does this issue occur? -- 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] Pulsar Release 2.9.2 Candidate 2
Penghui, Gao, see my comments below please Il giorno mar 8 feb 2022 alle ore 09:16 Hang Chen ha scritto: > > +1 (binding) > > Verified the following context. > 1. Checked the checksum and licenses > 2. Build from the source code successfully > 3. Start standalone and run pulsar-perf with produce and consume > 4. Checked the Pulsar function and stateful functions > 5. Run Pulsar with KOP and publish and consume successfully with Kafka > 3.1.0 client > > Best, > Hang > > PengHui Li 于2022年2月7日周一 18:01写道： > > > > +1 (binding) > > > > 1. Checked the signature > > 2. Build from the source successfully > > 3. Start standalone > > 4. Publish and consume successfully > > 5. Cassandra connect works well > > 6. Checked state function > > > > And passed our internal integration tests. > > > > Regards, > > Penghui > > > > On Mon, Feb 7, 2022 at 4:37 PM PengHui Li wrote: > > > > > It's not a regression in 2.9.2, we should not block the 2.9.2 release. > > > Instead, we can have the fix in 2.9.3. It depends on the timeline of 2.9.3...but we cannot "promise" we will follow up immediately with another release. My understanding is that now if you enable transactions then you cannot use regular Pulsar producers. And from 2.9 we said that Transactions are no more BETA This is very bad from my point of view. I agree that this is not a regression of 2.9.2 vs 2.9.1, but basically the Transactions feature is not usable There is already a PR open, with a good discussion. I believe that we should not hurry up in doing this release and we can fix the problem. We should fix the problem and then roll a new RC If my understanding is correct, then I am -1 in releasing this RC. If it is not correct, then I am happy to continue testing this RC. Enrico > > > > > > Penghui > > > > > > On Thu, Feb 3, 2022 at 8:42 PM Nicolò Boschi wrote: > > > > > >> Hi Ran, thanks for driving the release. > > >> > > >> I haven't tested the rc yet but I firmly believe we should include this > > >> pull [1] which fixes a regression introduced in Pulsar 2.9.0 > > >> > > >> [1] https://github.com/apache/pulsar/pull/14097 > > >> > > >> > > >> > > >> Il giorno mer 2 feb 2022 alle ore 08:34 Enrico Olivelli < > > >> eolive...@gmail.com> > > >> ha scritto: > > >> > > >> > (sorry for the late reply, I am still testing, I had some other > > >> > priorities). > > >> > > > >> > I hope that the community will test this RC and report back > > >> > > > >> > > > >> > Enrico > > >> > > > >> > Il giorno mar 25 gen 2022 alle ore 15:07 Ran Gao ha > > >> > scritto: > > >> > > > > >> > > Sorry, the 2.9.2 release candidate-1 has a wrong sign certificate. > > >> > > > > >> > > This is the second release candidate for Apache Pulsar, version > > >> > > 2.9.2. > > >> > > > > >> > > *** 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.9.2-candidate-2/ > > >> > > > > >> > > SHA-512 checksums: > > >> > > > > >> > > > > >> > > > >> 563f65582c5307b4ef1e0322958ed19d7c181fb8bb8d7b8cab06ab0a6adb5520f7d18b6f97960b93c3318815529a8b8721e00e9cc9484532a2e5ed3221450094 > > >> > > ./apache-pulsar-2.9.2-bin.tar.gz > > >> > > > > >> > > > >> 60d1049611b938b0ddc769132124d43820728afc8a06813a5ec9efc095c5497c59d9bbcaaf7df5b0c0e97e051d66f59c1f8ee08885d05ca2c635773e0283770a > > >> > > ./apache-pulsar-2.9.2-src.tar.gz > > >> > > > > >> > > Maven staging repo: > > >> > > > > >> https://repository.apache.org/content/repositories/orgapachepulsar-1136 > > >> > > > > >> > > The tag to be voted upon: > > >> > > v2.9.2-candidate-2 (8a5d2253b888b3b865a2aedf635d672821c7) > > >> > > https://github.com/apache/pulsar/releases/tag/v2.9.2-candidate-2 > > >> > > > > >> > > Pulsar's KEYS file containing PGP keys we use to sign the release: > > >> > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS > > >> > > > > >> > > Please download the source package, and follow the README to build > > >> > > and run the Pulsar standalone service. > > >> > > > >> > > >> > > >> -- > > >> Nicolò Boschi > > >> > > >
Re: [DISCUSS] PIP-139 : Support Broker send command to real close producer/consumer.
> This is supposed to mean that the namespace should be able to be > deleted, correct? Yes, the main background is the user doesn’t have an active topic. so, they want to delete the namespace. > However, I think > we might still have a race condition that could make tenant or > namespace deletion fail. Specifically, if a new producer or consumer > creates a topic after the namespace deletion has started but > before it is complete. Do you agree that the underlying race still exists? Yes, this condition exists. I think it’s not a big problem because the user doesn’t want to use this namespace anymore. If this scenario appears, they will get an error and need to delete it again. > What if we expand our usage of the "terminated" feature to apply to > namespaces (and tenants)? Then, a terminated namespace can have > bundles and topics can be deleted but not created (just as a terminated > topic cannot have any new messages published to it). This would take > care of all topic creation race conditions. We'd probably need to add > new protobuf exceptions for this feature. If we want to solve this problem, we need to add some sync resources like lock/state, I think it’s a harm for us, we don’t need to do that. Thanks for your suggestions, let me know what you think. Best, Mattison > On Feb 1, 2022, at 2:26 PM, Michael Marshall wrote: > > This proposal identifies an important issue that we should definitely > solve. I have some questions. > >> When there are no user-created topics under a namespace, >> Namespace should be deleted. > > This is supposed to mean that the namespace should be able to be > deleted, correct? > >> For this reason, we need to close the system topic reader/producer >> first, then remove the system topic. finally, remove the namespace. > > I agree that expanding the protobuf CloseProducer and CloseConsumer > commands could be valuable here. The expansion would ensure that > producers and consumers don't attempt to reconnect. However, I think > we might still have a race condition that could make tenant or > namespace deletion fail. Specifically, if a new producer or consumer > creates a topic after the namespace deletion has started but > before it is complete. Do you agree that the underlying race still exists? > > In my view, the fundamental problem here is that deleting certain Pulsar > resources takes time and, in a distributed system, that means race > conditions. > > What if we expand our usage of the "terminated" feature to apply to > namespaces (and tenants)? Then, a terminated namespace can have > bundles and topics can be deleted but not created (just as a terminated > topic cannot have any new messages published to it). This would take > care of all topic creation race conditions. We'd probably need to add > new protobuf exceptions for this feature. > > Thanks, > Michael > > > On Sat, Jan 29, 2022 at 7:25 PM Zike Yang > wrote: >> >> +1 >> >> >> Thanks, >> Zike >> >> On Sat, Jan 29, 2022 at 12:30 PM guo jiwei wrote: >>> >>> Hi >>> The PIP link : https://github.com/apache/pulsar/issues/13989 >>> >>> Regards >>> Jiwei Guo (Tboy) >>> >>> >>> On Sat, Jan 29, 2022 at 11:46 AM mattison chao >>> wrote: >>> Hello everyone, I want to start a discussion about PIP-139 : Support Broker send command to real close producer/consumer. This is the PIP document https://github.com/apache/pulsar/issues/13989 < https://github.com/apache/pulsar/issues/13979> Please check it out and feel free to share your thoughts. Best, Mattison Pasted below for quoting convenience. Relation pull request: #13337 Authors: @Technoboy- @mattisonchao ## Motivation Before we discuss this pip, I'd like to supplement some context to help contributors who don't want to read the original pull request. > When there are no user-created topics under a namespace, Namespace should be deleted. But currently, the system topic existed and the reader/producer could auto-create the system which may cause the namespace deletion to fail. For this reason, we need to close the system topic reader/producer first, then remove the system topic. finally, remove the namespace. Following this way, we first want to use ``terminate`` to solve this problem. then we found producers can disconnect, but consumers are still alive. So, another PR #13960 wants to add consumers' closing logic. After #13960, all things look good, but another problem appears. that is we need to wait until consumers completely consume all messages (this may make terminate topic so long and the operation timeout)then get ``reachedEndOfTopic``. the relative code here : https://github.com/apache/pulsar/blob/07ef9231db8b844586b9217ee2d59237eb9c54b7/pulsar-broker/src/main/java/org/apache/
[DISCUSS] PIP 141 : Pulsar BOM
Hi everyone, I'd like to open a discussion on PIP 141 : Pulsar BOM The PIP is here : https://github.com/apache/pulsar/issues/14168 ## Motivation When designing NAR modules loaded by Nifi in the broker such as protocol handlers, proxy extensions, Pulsar IO connectors, etc..., it's important that the dependencies that are common to the module and the broker are as close as possible to prevent incompatible library exceptions (NoSuchClassError, NoSuchMethodError, IncompatibleClassChangeError, etc ...) at runtime. If a class is both in the NAR and in the broker, the broker one will be loaded. ## Goal This proposal is to define a BOM (Bill Of Materials) for Pulsar. A BOM is a special kind of POM that contains all the dependency versions that are used by the project and can be imported in another project. Currently there is a `dependencyManagement` section in Pulsar's parent POM but it's not always possible to derive from this parent POM as it imports a lot more things than the dependency versions and external projects usually prefer to have their own parent POM. External projects can import this BOM and use the same library versions as Pulsar at compile/test time. ## API Changes No API changes ## Implementation The `dependencyManagement` section of Pulsar's parent POM and related properties will be extracted in a POM and put in a `pulsar-bom` directory. The `pulsar-bom` artifact shall be built and released independently from the rest of Pulsar project (not a maven module). The Pulsar's parent POM `dependencyManagement` section is replaced by: org.apache.pulsar pulsar-bom 2.10.0-SNAPSHOT pom import The CI will have to build `pulsar-bom` before building Pulsar. ## Reject Alternatives The BOM could be part of a distinct Git project. This would be harder to handle for contributions that modify both the BOM and Pulsar. Thanks a lot for your feedback ! Christophe
[GitHub] [pulsar-helm-chart] elangelo commented on pull request #225: allow specifying the nodeSelector for the init jobs
elangelo commented on pull request #225: URL: https://github.com/apache/pulsar-helm-chart/pull/225#issuecomment-1032828708 > Thanks for the PR. Would it be possible to use the key `pulsar_metadata.nodeSelector` instead of `initialize_jobs.nodeSelector`? Please also add a placeholder in the default values.yaml with a comment documenting the setting. The value should be empty. what do i do for the bookkeeper_cluster_initalize jobs? specify another nodeSelector value? or use the pulsar_metadata.nodeSelector value there as well? -- 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-helm-chart] pellicano commented on pull request #205: Tiered Storage config
pellicano commented on pull request #205: URL: https://github.com/apache/pulsar-helm-chart/pull/205#issuecomment-1032999802 Any news here, @michaeljmarshall? @sijie if you may please take a look. We appreciate. Thank you. -- 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-manager] jinoyparekh opened a new pull request #442: testing artifact
jinoyparekh opened a new pull request #442: URL: https://github.com/apache/pulsar-manager/pull/442 *(If this PR fixes a github issue, please add `Fixes #`.)* Fixes # *(or if this PR is one task of a github issue, please add `Master Issue: #` to link to the master issue.)* Master Issue: # ### Motivation *Explain here the context, and why you're making that change. What is the problem you're trying to solve.* ### Modifications *Describe the modifications you've done.* ### 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
[DISCUSS] moving storm adapter under Apache Storm
Hello, A while back during one of the community meetings we talked about pulsar-adapters repo not getting enough love - being missed during the releases, not keeping up with the pulsar changes etc. One of the ideas (from Sijie, as I recall) was to donate the adapters to other communities that have expertise and experience in the systems Pulsar integrates with. This happened with the Flink adapter and it got removed from the pulsar-adapters project recently. I made a first attempt on moving the Storm adapter under the Storm community umbrella and will appreciate feedback/help if any changes needed for this attempt: https://github.com/apache/storm/pull/3440 I haven't reached out to the Storm dev community yet because I was not sure what conflicts/incompatibilities this attempt will find. I will reach out to them after initial yey/nay from the Pulsar community. -- Andrey Yegorov
Re: [DISCUSS] PIP-136: Sync Pulsar policies across multiple clouds
>> How do we designate the host broker? Is it manual? How does it work when the host broker is removed from the cluster? No, it will not be manual but as I explained earlier a broker which has a failover consumer to consume remote events will be the publisher for metadata update. If that broker is removed then a new failover consumer/broker will be selected for the same. >> I look forward to seeing more about this design for conflict resolution. Sure, I have updated PIP to handle such race condition: https://github.com/apache/pulsar/issues/13728 >> (1) scenarios where the Pulsar cluster operators and tenant admins are different entities and tenants can be malicious, or more probably, write bad code that will produce malicious outcomes. I agree, Pulsar should have provision to prevent such scenarios where changes from one tenant in a cluster can impact other clusters. This PIP considers the tenant/admin will be the same at both the ends but that can not be true in all cases. We can add an enhancement later or we can create a separate PIP to start discussion with the possible solutions. Thanks, Rajan On Thu, Feb 3, 2022 at 9:59 AM Joe F wrote: > >On my first reading, it wasn't clear if there was only one topic > required for this feature. I now see that the topic is not tied to a > specific tenant or namespace. As such, we can avoid complicated > authorization questions by putting the required event topic(s) into a > "system" tenant and namespace > > We should consider complicated questions. We can say why we chose not to > address it, or why it does not apply. for a particular situation > > Many namespace policies are administered by tenants. As such any tenant > can load this topic. Is it possible for one abusive tenant to make your > system topic dysfunctional? > > Pulsar committers should think about > (1) scenarios where the Pulsar cluster operators and tenant admins are > different entities and tenants can be malicious, or more probably, write > bad code that will produce malicious outcomes. > (2) whether the changes introduce additional SPOFs into the cluster. > > I don't think this PIP has those issues, but as a matter of practice, I > would like to see backend/system PIPs consider these questions and > explicitly state the conclusions with rationale > > Joe > > > On Wed, Feb 2, 2022 at 9:27 PM Michael Marshall > wrote: > > > Thanks for your responses. > > > > > I don't see a need of protobuf for this particular usecase > > > > If no one else feels strongly on this point, I am good with using a POJO. > > > > > It doesn't matter if it's system-topic or not because it's > > > configurable and the admin of the system can decide and configure it > > > according to the required persistent policy. > > > > On my first reading, it wasn't clear if there was only one topic > > required for this feature. I now see that the topic is not tied to a > > specific tenant or namespace. As such, we can avoid complicated > > authorization questions by putting the required event topic(s) into a > > "system" tenant and namespace, by default. The `pulsar/system` tenant > > and namespace seem appropriate to me. > > > > > I would keep the system topic > > > separate because this topic serves a specific purpose with specific > > schema, > > > replication policy and retention policy. > > > > I think we need a more formal definition for system topics. This topic > > is exactly the kind of topic I would call a system topic: its intended > > producers and consumers are Pulsar components. However, because > > this feature can live on a topic in a system namespace, we can avoid > > the classification discussion for this PIP. > > > > > Source region will have a broker which will create a failover consumer > on > > > that topic and a broker with an active consumer will watch the metadata > > > changes and publish the changes to the event topic. > > > > How do we designate the host broker? Is it manual? How does it work > > when the host broker is removed from the cluster? > > > > If we collocate the active consumer with the broker hosting the event > > topic, can we skip creating the failover consumer? > > > > > PIP briefly talks about it but I will update the PIP with more > > > explanation. > > > > I look forward to seeing more about this design for conflict resolution. > > > > Thanks, > > Michael > > > > > > > > On Tue, Feb 1, 2022 at 3:01 AM Rajan Dhabalia > > wrote: > > > > > > Please find my response inline. > > > > > > On Mon, Jan 31, 2022 at 9:17 PM Michael Marshall > > > > wrote: > > > > > > > I think this is a very appropriate direction to take Pulsar's > > > > geo-replication. Your proposal is essentially to make the > > > > inter-cluster configuration event driven. This increases fault > > > > tolerance and better decouples clusters. > > > > > > > > Thank you for your detailed proposal. After reading through it, I > have > > > > some questions :) > > > > > > > > 1. What do you think about using protobuf t
[GitHub] [pulsar-manager] jamesvsshark commented on issue #283: Pulsar Manager keeps saying "This environment is error. Please check it"
jamesvsshark commented on issue #283: URL: https://github.com/apache/pulsar-manager/issues/283#issuecomment-1033264016 Using `http://pulsar:8080` as the service url works for me. -- 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-manager] tuteng merged pull request #440: Add filterable to el-select enables filtering for tenant/namespace/topic
tuteng merged pull request #440: URL: https://github.com/apache/pulsar-manager/pull/440 -- 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-manager] tuteng commented on a change in pull request #442: testing artifact
tuteng commented on a change in pull request #442: URL: https://github.com/apache/pulsar-manager/pull/442#discussion_r802223026 ## File path: .github/workflows/gradle.yml ## @@ -1,23 +1,30 @@ -name: Java CI + name: Java CI -on: - push: -branches: - - master - pull_request: -branches: - - master + on: Review comment: Just wondering why a space was added -- 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] Pulsar Release 2.9.2 Candidate 2
Hi enrico, There are some other ongoing transaction fixes, we can't wait for all of them to be completed Please move them to 2.9.3 and don't block the 2.9.2 release. And https://github.com/apache/pulsar/pull/14097 also in the discussion stage, We should keep calm at this time, no need to hurry to merge a 100% clear plan, otherwise, we might introduce other regression in 2.9.2. Another point is non-transaction users are much larger than transaction users for now, there are many critical issue fixes in 2.9.2, I see many users can't wait for our release, they build from the branch-2.9 manually. We should follow the time-based release mode. If the release doesn't have critical security issues, regressions. we should not block the release, instead, we should prepare for the release of 2.9.3 earlier. If the time-based release doesn't work, I think we should have a discussion in the private email list to find a good solution for Pulsar release, Let everyone keep consistent on the rules for release. Regards, Penghui On Tue, Feb 8, 2022 at 5:04 PM Enrico Olivelli wrote: > Penghui, Gao, > see my comments below please > > Il giorno mar 8 feb 2022 alle ore 09:16 Hang Chen > ha scritto: > > > > +1 (binding) > > > > Verified the following context. > > 1. Checked the checksum and licenses > > 2. Build from the source code successfully > > 3. Start standalone and run pulsar-perf with produce and consume > > 4. Checked the Pulsar function and stateful functions > > 5. Run Pulsar with KOP and publish and consume successfully with Kafka > > 3.1.0 client > > > > Best, > > Hang > > > > PengHui Li 于2022年2月7日周一 18:01写道： > > > > > > +1 (binding) > > > > > > 1. Checked the signature > > > 2. Build from the source successfully > > > 3. Start standalone > > > 4. Publish and consume successfully > > > 5. Cassandra connect works well > > > 6. Checked state function > > > > > > And passed our internal integration tests. > > > > > > Regards, > > > Penghui > > > > > > On Mon, Feb 7, 2022 at 4:37 PM PengHui Li wrote: > > > > > > > It's not a regression in 2.9.2, we should not block the 2.9.2 > release. > > > > Instead, we can have the fix in 2.9.3. > > It depends on the timeline of 2.9.3...but we cannot "promise" we will > follow up immediately with another release. > > My understanding is that now if you enable transactions then you > cannot use regular Pulsar producers. > And from 2.9 we said that Transactions are no more BETA > > This is very bad from my point of view. > > I agree that this is not a regression of 2.9.2 vs 2.9.1, but basically > the Transactions feature is not usable > > There is already a PR open, with a good discussion. > I believe that we should not hurry up in doing this release and we can > fix the problem. > > We should fix the problem and then roll a new RC > > If my understanding is correct, then I am -1 in releasing this RC. > If it is not correct, then I am happy to continue testing this RC. > > Enrico > > > > > > > > > > > > Penghui > > > > > > > > On Thu, Feb 3, 2022 at 8:42 PM Nicolò Boschi > wrote: > > > > > > > >> Hi Ran, thanks for driving the release. > > > >> > > > >> I haven't tested the rc yet but I firmly believe we should include > this > > > >> pull [1] which fixes a regression introduced in Pulsar 2.9.0 > > > >> > > > >> [1] https://github.com/apache/pulsar/pull/14097 > > > >> > > > >> > > > >> > > > >> Il giorno mer 2 feb 2022 alle ore 08:34 Enrico Olivelli < > > > >> eolive...@gmail.com> > > > >> ha scritto: > > > >> > > > >> > (sorry for the late reply, I am still testing, I had some other > > > >> > priorities). > > > >> > > > > >> > I hope that the community will test this RC and report back > > > >> > > > > >> > > > > >> > Enrico > > > >> > > > > >> > Il giorno mar 25 gen 2022 alle ore 15:07 Ran Gao > ha > > > >> > scritto: > > > >> > > > > > >> > > Sorry, the 2.9.2 release candidate-1 has a wrong sign > certificate. > > > >> > > > > > >> > > This is the second release candidate for Apache Pulsar, version > 2.9.2. > > > >> > > > > > >> > > *** 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.9.2-candidate-2/ > > > >> > > > > > >> > > SHA-512 checksums: > > > >> > > > > > >> > > > > > >> > > > > >> > 563f65582c5307b4ef1e0322958ed19d7c181fb8bb8d7b8cab06ab0a6adb5520f7d18b6f97960b93c3318815529a8b8721e00e9cc9484532a2e5ed3221450094 > > > >> > > ./apache-pulsar-2.9.2-bin.tar.gz > > > >> > > > > > >> > > > > >> > 60d1049611b938b0ddc769132124d43820728afc8a06813a5ec9efc095c5497c59d9bbcaaf7df5b0c0e97e051d66f59c1f8ee08885d05ca2c635773e0283770a > > > >> > > ./apache-pulsar-2.9.2-src.tar.gz > > > >> > > > > > >> > > Maven staging repo: > > >
Re: [VOTE] Pulsar Release 2.9.2 Candidate 2
I am -0 for this release because of the transaction regression, assuming it is as bad as Enrico described. I don't know enough about the transaction feature's stability to give a "-1". > There are some other ongoing transaction fixes, we can't wait for all of > them to be completed Does this mean that transactions are not yet stable in 2.9? I think we need to clarify this point and then communicate that to our users. > We should follow the time-based release mode. Our time based release plan defined in PIP 47 does not define a timeline for patch releases. Regarding patch releases, it only says "We will also attempt, as a community to do bugfix releases as needed for the last 4 releases.". > I see many users can't wait for our release, > they build from the branch-2.9 manually. I do not consider this a failure. One of the benefits of using an open source project is that you can build it yourself. Given that users have this option, I think we should strive for releases without large, known regressions for stable features. We may not have known about this regression in 2.9.1, but we know about it now, before the 2.9.2 vote has closed. > If the time-based release doesn't work, I think we should have a discussion > in the private email list I request this discussion happen on the dev list to allow for user and contributor feedback. Thanks, Michael On Tue, Feb 8, 2022 at 11:08 PM PengHui Li wrote: > > Hi enrico, > > There are some other ongoing transaction fixes, we can't wait for all of > them to be completed > Please move them to 2.9.3 and don't block the 2.9.2 release. > > And https://github.com/apache/pulsar/pull/14097 also in the discussion > stage, > We should keep calm at this time, no need to hurry to merge a 100% clear > plan, > otherwise, we might introduce other regression in 2.9.2. > > Another point is non-transaction users are much larger than transaction > users for now, > there are many critical issue fixes in 2.9.2, I see many users can't wait > for our release, > they build from the branch-2.9 manually. > > We should follow the time-based release mode. If the release doesn't have > critical security issues, regressions. > we should not block the release, instead, we should prepare for the release > of 2.9.3 earlier. > > If the time-based release doesn't work, I think we should have a discussion > in the private email list > to find a good solution for Pulsar release, Let everyone keep consistent on > the rules for release. > > Regards, > Penghui > > On Tue, Feb 8, 2022 at 5:04 PM Enrico Olivelli wrote: > > > Penghui, Gao, > > see my comments below please > > > > Il giorno mar 8 feb 2022 alle ore 09:16 Hang Chen > > ha scritto: > > > > > > +1 (binding) > > > > > > Verified the following context. > > > 1. Checked the checksum and licenses > > > 2. Build from the source code successfully > > > 3. Start standalone and run pulsar-perf with produce and consume > > > 4. Checked the Pulsar function and stateful functions > > > 5. Run Pulsar with KOP and publish and consume successfully with Kafka > > > 3.1.0 client > > > > > > Best, > > > Hang > > > > > > PengHui Li 于2022年2月7日周一 18:01写道： > > > > > > > > +1 (binding) > > > > > > > > 1. Checked the signature > > > > 2. Build from the source successfully > > > > 3. Start standalone > > > > 4. Publish and consume successfully > > > > 5. Cassandra connect works well > > > > 6. Checked state function > > > > > > > > And passed our internal integration tests. > > > > > > > > Regards, > > > > Penghui > > > > > > > > On Mon, Feb 7, 2022 at 4:37 PM PengHui Li wrote: > > > > > > > > > It's not a regression in 2.9.2, we should not block the 2.9.2 > > release. > > > > > Instead, we can have the fix in 2.9.3. > > > > It depends on the timeline of 2.9.3...but we cannot "promise" we will > > follow up immediately with another release. > > > > My understanding is that now if you enable transactions then you > > cannot use regular Pulsar producers. > > And from 2.9 we said that Transactions are no more BETA > > > > This is very bad from my point of view. > > > > I agree that this is not a regression of 2.9.2 vs 2.9.1, but basically > > the Transactions feature is not usable > > > > There is already a PR open, with a good discussion. > > I believe that we should not hurry up in doing this release and we can > > fix the problem. > > > > We should fix the problem and then roll a new RC > > > > If my understanding is correct, then I am -1 in releasing this RC. > > If it is not correct, then I am happy to continue testing this RC. > > > > Enrico > > > > > > > > > > > > > > > > > > Penghui > > > > > > > > > > On Thu, Feb 3, 2022 at 8:42 PM Nicolò Boschi > > wrote: > > > > > > > > > >> Hi Ran, thanks for driving the release. > > > > >> > > > > >> I haven't tested the rc yet but I firmly believe we should include > > this > > > > >> pull [1] which fixes a regression introduced in Pulsar 2.9.0 > > > > >> > > > > >> [1] https://github.com/apache/pulsar/pull/14097
