Re: [PROPOSAL] Roadmap for 3.0 release
+1 - this timeline sounds even better :) On Sat, Feb 18, 2023 at 12:41 AM Matteo Merli wrote: > > Ups, > > I started from the release date I was meaning April for the RCs: > > * Tue - 2023-04-11 > * Tue - 2023-04-18 - RC-2 > * Tue - 2023-04-25 - RC-3 > * Tue - 2023-05-02 - Announce 3.0 Release > > Sorry for the mixup! > > -- > Matteo Merli > > > > On Fri, Feb 17, 2023 at 10:39 PM Dave Fisher wrote: > > > +1. > > > > I think that there is a typo. See below. > > > > Sent from my iPhone > > > > > On Feb 17, 2023, at 2:44 PM, Matteo Merli wrote: > > > > > > Since the LTS release model has been formally approved, I'm proposing > > > the following schedule for the release: > > > > > > * Tue - 2023-05-11 > > > - RC-1 > > > - Code Freeze -- Only critical fixes will be merged in the 3.0 > > > release branch. Contributors should plan to have all the changes merged > > in > > > before this date. Exceptions should be extremely rare and strongly > > > motivated. > > > > > > * Tue - 2023-05-18 - RC-2 > > > * Tue - 2023-05-25 - RC-3 > > > * Tue - 2023-05-02 - Announce 3.0 Release > > > > You meant June 2, 2023? > > > > Best, > > Dave > > > > > > These dates will be published on the website to present users with a > > > "roadmap" and we should commit to and respect these dates. > > > > > > I also wanted to propose trying out a model where we have 3 release > > > managers for all major releases. > > > > > > The reasoning behind this is for this small group of people to > > collaborate > > > and divide the tasks for the release: merging patches from the "master" > > > branch, preparing RC, and testing. > > > > > > Since everyone also has other work duties and unexpected tasks that can > > pop > > > up at any time, it will help to have redundancy in the release-management > > > "team", so that we can release on the exact dates. > > > > > > Thanks, > > > Matteo > > > > > > -- > > > Matteo Merli > > > > > > >
Re: [PROPOSAL] Roadmap for 3.0 release
Ups, I started from the release date I was meaning April for the RCs: * Tue - 2023-04-11 * Tue - 2023-04-18 - RC-2 * Tue - 2023-04-25 - RC-3 * Tue - 2023-05-02 - Announce 3.0 Release Sorry for the mixup! -- Matteo Merli On Fri, Feb 17, 2023 at 10:39 PM Dave Fisher wrote: > +1. > > I think that there is a typo. See below. > > Sent from my iPhone > > > On Feb 17, 2023, at 2:44 PM, Matteo Merli wrote: > > > > Since the LTS release model has been formally approved, I'm proposing > > the following schedule for the release: > > > > * Tue - 2023-05-11 > > - RC-1 > > - Code Freeze -- Only critical fixes will be merged in the 3.0 > > release branch. Contributors should plan to have all the changes merged > in > > before this date. Exceptions should be extremely rare and strongly > > motivated. > > > > * Tue - 2023-05-18 - RC-2 > > * Tue - 2023-05-25 - RC-3 > > * Tue - 2023-05-02 - Announce 3.0 Release > > You meant June 2, 2023? > > Best, > Dave > > > > These dates will be published on the website to present users with a > > "roadmap" and we should commit to and respect these dates. > > > > I also wanted to propose trying out a model where we have 3 release > > managers for all major releases. > > > > The reasoning behind this is for this small group of people to > collaborate > > and divide the tasks for the release: merging patches from the "master" > > branch, preparing RC, and testing. > > > > Since everyone also has other work duties and unexpected tasks that can > pop > > up at any time, it will help to have redundancy in the release-management > > "team", so that we can release on the exact dates. > > > > Thanks, > > Matteo > > > > -- > > Matteo Merli > > > >
Re: [PROPOSAL] Roadmap for 3.0 release
+1. I think that there is a typo. See below. Sent from my iPhone > On Feb 17, 2023, at 2:44 PM, Matteo Merli wrote: > > Since the LTS release model has been formally approved, I'm proposing > the following schedule for the release: > > * Tue - 2023-05-11 > - RC-1 > - Code Freeze -- Only critical fixes will be merged in the 3.0 > release branch. Contributors should plan to have all the changes merged in > before this date. Exceptions should be extremely rare and strongly > motivated. > > * Tue - 2023-05-18 - RC-2 > * Tue - 2023-05-25 - RC-3 > * Tue - 2023-05-02 - Announce 3.0 Release You meant June 2, 2023? Best, Dave > > These dates will be published on the website to present users with a > "roadmap" and we should commit to and respect these dates. > > I also wanted to propose trying out a model where we have 3 release > managers for all major releases. > > The reasoning behind this is for this small group of people to collaborate > and divide the tasks for the release: merging patches from the "master" > branch, preparing RC, and testing. > > Since everyone also has other work duties and unexpected tasks that can pop > up at any time, it will help to have redundancy in the release-management > "team", so that we can release on the exact dates. > > Thanks, > Matteo > > -- > Matteo Merli >
Re: [PROPOSAL] Roadmap for 3.0 release
+1 awesome plan. Thanks, Zixuan Michael Marshall 于2023年2月18日周六 14:33写道： > +1 I support this timeline. > > > I also wanted to propose trying out a model where we have 3 release > > managers for all major releases. > > Great idea, this will be a valuable improvement to our release > process. It also creates an opportunity for new committers to ease > into the release management role. > > Thanks, > Michael > > On Fri, Feb 17, 2023 at 4:44 PM Matteo Merli wrote: > > > > Since the LTS release model has been formally approved, I'm proposing > > the following schedule for the release: > > > > * Tue - 2023-05-11 > >- RC-1 > >- Code Freeze -- Only critical fixes will be merged in the 3.0 > > release branch. Contributors should plan to have all the changes merged > in > > before this date. Exceptions should be extremely rare and strongly > > motivated. > > > > * Tue - 2023-05-18 - RC-2 > > * Tue - 2023-05-25 - RC-3 > > * Tue - 2023-05-02 - Announce 3.0 Release > > > > These dates will be published on the website to present users with a > > "roadmap" and we should commit to and respect these dates. > > > > I also wanted to propose trying out a model where we have 3 release > > managers for all major releases. > > > > The reasoning behind this is for this small group of people to > collaborate > > and divide the tasks for the release: merging patches from the "master" > > branch, preparing RC, and testing. > > > > Since everyone also has other work duties and unexpected tasks that can > pop > > up at any time, it will help to have redundancy in the release-management > > "team", so that we can release on the exact dates. > > > > Thanks, > > Matteo > > > > -- > > Matteo Merli > > >
Re: [PROPOSAL] Roadmap for 3.0 release
+1 I support this timeline. > I also wanted to propose trying out a model where we have 3 release > managers for all major releases. Great idea, this will be a valuable improvement to our release process. It also creates an opportunity for new committers to ease into the release management role. Thanks, Michael On Fri, Feb 17, 2023 at 4:44 PM Matteo Merli wrote: > > Since the LTS release model has been formally approved, I'm proposing > the following schedule for the release: > > * Tue - 2023-05-11 >- RC-1 >- Code Freeze -- Only critical fixes will be merged in the 3.0 > release branch. Contributors should plan to have all the changes merged in > before this date. Exceptions should be extremely rare and strongly > motivated. > > * Tue - 2023-05-18 - RC-2 > * Tue - 2023-05-25 - RC-3 > * Tue - 2023-05-02 - Announce 3.0 Release > > These dates will be published on the website to present users with a > "roadmap" and we should commit to and respect these dates. > > I also wanted to propose trying out a model where we have 3 release > managers for all major releases. > > The reasoning behind this is for this small group of people to collaborate > and divide the tasks for the release: merging patches from the "master" > branch, preparing RC, and testing. > > Since everyone also has other work duties and unexpected tasks that can pop > up at any time, it will help to have redundancy in the release-management > "team", so that we can release on the exact dates. > > Thanks, > Matteo > > -- > Matteo Merli >
Re: [DISCUSS] PIP-242 Topic name restrictions
I support breaking this into two PIPs. It was my fault the two PIPs were merged in the first place. I am sorry if I created any confusion. My intention was only to point out that names are a meaningful way to simplify logic, and we should reserve certain names for Pulsar's own usage with a well defined pattern so that we can simplify lifecycle operations. Thanks, Michael On Fri, Feb 17, 2023 at 1:55 AM Enrico Olivelli wrote: > > Mattison, > > Il giorno gio 16 feb 2023 alle ore 00:27 ha scritto: > > > > > I am sorry but I am not sure that this is enough to preventreads/writes > > > from unallowed clients. > > IMO, We can consider the authorisation part in another PIP because We are > > just focusing on adding the topic name constraint of topic creation. > > > > Maybe we can use another PIP to clearify all of system topic's behaviour, > > like authorisation something. > > e.g. we just allow superusers to read/write the data to that system topic. > > > We should elaborate more on this topic on the PIP > > I will add the internal system topic creation logic in the PIP. > Why do you think that this is enough ? > > I think that we are going off the initial scope of the PIP. > The initial problem is about preventing clients from creating topics > that contain the "-partition-" keyword. > > I totally agree that there must be a clear way to distinguish topics > that are not meant to be accessed by "regular clients". > > The answer is in Micheal's words: only super users are allowed to > access topics that are not meant to be accessed by clients. > Broker to Broker communications are always running with a "super user" > role, so it is not a problem. > > BTW I wonder if it is better to narrow down the scope of the PIP and > go back to "-partition-" > > > Enrico > > > > > > Best, > > Mattison > > On Feb 16, 2023, 00:41 +0800, Enrico Olivelli , wrote: > > > Il giorno mer 15 feb 2023 alle ore 17:07 ha > > > scritto: > > > > > > > > Hi Enrico > > > > > > > > I think it's a good question. We can introduce a new method in the > > > > BrokerService to help brokers create the topic internally first(maybe > > > > just metadata is enough), and then to use a pulsar client to connect to > > > > it. > > > > > > I am sorry but I am not sure that this is enough to prevent > > > reads/writes from unallowed clients. > > > We should elaborate more on this topic on the PIP > > > > > > Enrico > > > > > > > > > > > WDYT? > > > > > > > > > > > > Best, > > > > Mattison > > > > On Feb 16, 2023, 00:01 +0800, Enrico Olivelli , > > > > wrote: > > > > > > I have one question (apologies for the top posting). > > > > > > > > > > > > The Broker (and the other Pulsar components) use the regular Pulsar > > > > > > client to connect to "system topics" > > > > > > and in general they use the Pulsar wire protocol. > > > > > > > > > > > > The question is "how do you distinguish an internal component from a > > > > > > user component ?" > > > > > > How can you say that the broker is able to connect to a system topic > > > > > > and any other client cannot do it ? > > > > > > > > > > > > Enrico > > > > > > > > > > > > Il giorno mer 15 feb 2023 alle ore 15:38 > > > > > > ha scritto: > > > > > > > > > > > > > > > > Hi Asaf > > > > > > > > > > > > > > > > There is a link to introduce the dynamic configuration. > > > > > > > > https://pulsar.apache.org/docs/2.10.x/admin-api-brokers/#dynamic-broker-configuration > > > > > > > > > > > > > > > > Best, > > > > > > > > Mattison > > > > > > > > On Feb 14, 2023, 17:06 +0800, Asaf Mesika > > > > > > > > , wrote: > > > > > > > > > > > > On Tue, Feb 14, 2023 at 3:46 AM > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, Asaf > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Welcome to join this discussion. > > > > > > > > > > > > > > > > > > > > > > > > You mean that allows the > > > > > > > > > > > > > > > > > > > > > > > > *system* to use it when it's a > > > > > > > > > > > > > > > > > > > > > > > > partitioned > > > > > > > > > > > > > > > > topic? > > > > > > > > > > > > > > > > Sorry, I didn't get your point. What do you > > > > > > > > > > > > > > > > mean by *system*? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This sentence was a reply to: > > > > > > > > > > > > > > > > > > > > > > > > 2. Make the `-partition-` string the keyword. That > > > > > > > > > > > > allows the user to use > > > > > > > > > > > > > > > > it when it's a partitioned topic. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I wanted to say that this sentence should be: > > > > > > > > > > > > Make the `-partition-` string the keyword, that allows > > > > > > > > > > > > the *system* to use > > > > > > > > > > > > it when it's a partitioned topic. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Why postfix of `__`?Why > > > >
Re: [DISCUSS] Using jetty-client instead of async-http-client
Hi all, Thank your for your point! Closed now. Thanks, Zixuan Matteo Merli 于2023年2月18日周六 06:36写道： > Async-http-client has always been super-stable in the past and is being > used by many other Java projects. I don't see any risk of being abandoned. > The fact that activity was quiet is mostly related to this project being > "complete" from a feature standpoint (which is good). > > The alternatives are really not "async" and would cause a lot of > performance regressions and other headaches. > > > -- > Matteo Merli > > > > On Thu, Feb 16, 2023 at 5:52 AM Asaf Mesika wrote: > > > Oh. I looked at the commits, it seems pretty active to me. > > > > > > On Thu, Feb 16, 2023 at 3:31 PM Zixuan Liu wrote: > > > > > I point to async-http-client. > > > > > > Although there is a recent update. > > > > > > Thanks, > > > Zixuan > > > > > > Asaf Mesika 于2023年2月16日周四 21:19写道： > > > > > > > On Tue, Feb 14, 2023 at 11:36 AM Zixuan Liu > wrote: > > > > > > > > > Hi all, > > > > > > > > > > Our admin-client using the async-http-client [0] to request the web > > > > > service, the async-http-client implements network request based on > > the > > > > > netty, which has very good performance, but this project is not > very > > > > > active. > > > > > > > > > > > > > Netty - the most used network server in the world - is not very > active? > > > > > > > > > > > > > > > > > > For security(library) reason or http feature(Follow up on future > > > > > development), could we migrate to the jetty-client [1] from the > > > > > async-http-client? The jetty project is very active, our web > service > > is > > > > > built based on the jetty-server, so I think use the jett-client is > a > > > good > > > > > idea, but migrating this can be a lot of work. > > > > > > > > > > Please let me know what you think. > > > > > > > > > > [0] - https://github.com/AsyncHttpClient/async-http-client > > > > > [1] - https://github.com/eclipse/jetty.project/tree/jetty-9.4.x > > > > > > > > > > Thanks, > > > > > Zixuan > > > > > > > > > > > > > > >
[PROPOSAL] Roadmap for 3.0 release
Since the LTS release model has been formally approved, I'm proposing the following schedule for the release: * Tue - 2023-05-11 - RC-1 - Code Freeze -- Only critical fixes will be merged in the 3.0 release branch. Contributors should plan to have all the changes merged in before this date. Exceptions should be extremely rare and strongly motivated. * Tue - 2023-05-18 - RC-2 * Tue - 2023-05-25 - RC-3 * Tue - 2023-05-02 - Announce 3.0 Release These dates will be published on the website to present users with a "roadmap" and we should commit to and respect these dates. I also wanted to propose trying out a model where we have 3 release managers for all major releases. The reasoning behind this is for this small group of people to collaborate and divide the tasks for the release: merging patches from the "master" branch, preparing RC, and testing. Since everyone also has other work duties and unexpected tasks that can pop up at any time, it will help to have redundancy in the release-management "team", so that we can release on the exact dates. Thanks, Matteo -- Matteo Merli
Re: [DISCUSS] Using jetty-client instead of async-http-client
Async-http-client has always been super-stable in the past and is being used by many other Java projects. I don't see any risk of being abandoned. The fact that activity was quiet is mostly related to this project being "complete" from a feature standpoint (which is good). The alternatives are really not "async" and would cause a lot of performance regressions and other headaches. -- Matteo Merli On Thu, Feb 16, 2023 at 5:52 AM Asaf Mesika wrote: > Oh. I looked at the commits, it seems pretty active to me. > > > On Thu, Feb 16, 2023 at 3:31 PM Zixuan Liu wrote: > > > I point to async-http-client. > > > > Although there is a recent update. > > > > Thanks, > > Zixuan > > > > Asaf Mesika 于2023年2月16日周四 21:19写道： > > > > > On Tue, Feb 14, 2023 at 11:36 AM Zixuan Liu wrote: > > > > > > > Hi all, > > > > > > > > Our admin-client using the async-http-client [0] to request the web > > > > service, the async-http-client implements network request based on > the > > > > netty, which has very good performance, but this project is not very > > > > active. > > > > > > > > > > Netty - the most used network server in the world - is not very active? > > > > > > > > > > > > > > For security(library) reason or http feature(Follow up on future > > > > development), could we migrate to the jetty-client [1] from the > > > > async-http-client? The jetty project is very active, our web service > is > > > > built based on the jetty-server, so I think use the jett-client is a > > good > > > > idea, but migrating this can be a lot of work. > > > > > > > > Please let me know what you think. > > > > > > > > [0] - https://github.com/AsyncHttpClient/async-http-client > > > > [1] - https://github.com/eclipse/jetty.project/tree/jetty-9.4.x > > > > > > > > Thanks, > > > > Zixuan > > > > > > > > > >
Re: [VOTE] PIP-175: Extend time based release process
Hi Haiting, We'll publish the LTS and end-of-life policy on the website, with the support dates for each release. -- Matteo Merli On Mon, Feb 13, 2023 at 6:27 PM Haiting Jiang wrote: > Hi Matteo, > > I noticed that 2.10 is not mentioned to be the first LTS version as > discussed previously. > Should we include this? > > Thanks, > Haiting > > On Mon, Feb 13, 2023 at 10:26 AM Yunze Xu > wrote: > > > > +1 (binding) > > > > Thanks, > > Yunze > > > > On Thu, Feb 9, 2023 at 6:47 PM Nicolò Boschi > wrote: > > > > > > +1 (binding) > > > > > > Nicolò Boschi > > > > > > > > > Il giorno gio 9 feb 2023 alle ore 11:17 Zike Yang ha > > > scritto: > > > > > > > +1 (non-binding) > > > > > > > > Thanks, > > > > Zike Yang > > > > > > > > On Thu, Feb 9, 2023 at 5:28 PM PengHui Li > wrote: > > > > > > > > > > +1 (binding) > > > > > > > > > > Penghui > > > > > > > > > > > On Feb 9, 2023, at 17:24, Nozomi Kurihara > wrote: > > > > > > > > > > > > +1 > > > > > > > > > > > > The LTS plan seems clear and helpful for users. > > > > > > > > > > > > Thanks, > > > > > > Nozomi > > > > > > > > > > > > 2023年2月9日(木) 5:44 Matteo Merli : > > > > > > > > > > > >> https://github.com/apache/pulsar/issues/15966 > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > >> ## Motivation > > > > > >> > > > > > >> In PIP-47 ( > > > > > >> > https://github.com/apache/pulsar/wiki/PIP-47:-Time-Based-Release-Plan), > > > > we > > > > > >> have adopted a time-based release plan. This was the first > attempt at > > > > > >> establishing a new principle on how releases should b > > > > > >> > > > > > >> The main two benefits of this approach have been: > > > > > >> > > > > > >> 1. Clarity for users and developers on when to expect a release > > > > > >> 2. Breaking a hard relationship between feature and release: a > > > > particular > > > > > >> feature will be included in the release if it is completed in > time. > > > > > >> Otherwise, it will be bubbled up to the next release. > > > > > >> > > > > > >> The motivation for the current proposal is to extend the > existing > > > > process > > > > > >> to address the issues that we have seen and that were left out > of the > > > > scope > > > > > >> of PIP-47. > > > > > >> > > > > > >> ## Summary of existing issues in the process > > > > > >> > > > > > >> ### Short maintenance cycles for releases > > > > > >> > > > > > >> Since we're doing a 3 months release cycle, we are ending with 4 > > > > releases > > > > > >> done per year, even though it's more close to 3 releases. > > > > > >> > > > > > >> There is a high cost to maintain a lot of old releases, > backport bug > > > > fixes, > > > > > >> and security patches. In general, we actively support the last > 3 minor > > > > > >> releases while continuing to develop the next release. E.g., > 2.8, > > > > 2.9, and > > > > > >> 2.10, while 2.11 is under development. > > > > > >> > > > > > >> The result is that a user adopting a particular release is > forced to > > > > > >> upgrade in a < 1-year timeframe to keep up to date and use a > supported > > > > > >> release. This timeframe is too short for many users as it > imposes a > > > > lot of > > > > > >> forced upgrades, for which they are not prepared in terms of > > > > available time > > > > > >> and required effort. > > > > > >> > > > > > >> ### Live Upgrade/Downgrade compatibility path > > > > > >> > > > > > >> In Pulsar, we guarantee that users have a way to do live > upgrades and > > > > > >> downgrades with zero downtime. > > > > > >> > > > > > >> This is very powerful because it gives them the freedom to > upgrade to > > > > a new > > > > > >> release with the assurance of being able to roll back to the > previous > > > > > >> release in case any functional or performance regressions are > > > > encountered. > > > > > >> > > > > > >> Today, this compatibility is guaranteed across minor versions. > Eg: I > > > > can do > > > > > >> `2.7 -> 2.8 -> 2.7` as a live upgrade. > > > > > >> > > > > > >> What is not guaranteed is to "skip" releases. E.g.: `2.7 -> 2.9` > > > > might work > > > > > >> or not, but it's not guaranteed. In that case an intermediated > upgrade > > > > > >> would be required: `2.7 -> 2.8 -> 2.9`. > > > > > >> > > > > > >> The reasons for which the "skip" upgrade might not work are > multiple: > > > > > >> 1. Incompatible upgrade of some dependency (e.g., ZooKeeper) > that > > > > might > > > > > >> not be compatible with an older version. > > > > > >> 2. Adoption of a new metadata format or data format on disk. > > > > > >> Every time we introduce a new incompatible format change > (outside > > > > of a > > > > > >> regular Protobuf field addition), we do it in a 2 steps way: > > > > > >> - In a new release, we introduce the new feature/format, > > > > disabled by > > > > > >> default. The new release can read both old and new formats, > though
Re: [VOTE] PIP-175: Extend time based release process
Thanks everyone for voting. I'm closing the vote with 8 binding +1s and 2 non-binding +1s Binding: * Matteo * Nozomi * PengHui * Nicolò * Yunze * Hang * Michael * Enrico Non-Binding: * Zike * Mattison -- Matteo Merli On Mon, Feb 13, 2023 at 11:06 PM Enrico Olivelli wrote: > +1 (binding) > > Enrico > > Il Mar 14 Feb 2023, 07:51 ha scritto: > > > +1(non-binding) > > > > Best, > > Mattison > > On Feb 9, 2023, 04:44 +0800, Matteo Merli , > wrote: > > > https://github.com/apache/pulsar/issues/15966 > > > > > > > > > > > > > > > > > > ## Motivation > > > > > > In PIP-47 ( > > > https://github.com/apache/pulsar/wiki/PIP-47:-Time-Based-Release-Plan > ), > > we > > > have adopted a time-based release plan. This was the first attempt at > > > establishing a new principle on how releases should b > > > > > > The main two benefits of this approach have been: > > > > > > 1. Clarity for users and developers on when to expect a release > > > 2. Breaking a hard relationship between feature and release: a > particular > > > feature will be included in the release if it is completed in time. > > > Otherwise, it will be bubbled up to the next release. > > > > > > The motivation for the current proposal is to extend the existing > process > > > to address the issues that we have seen and that were left out of the > > scope > > > of PIP-47. > > > > > > ## Summary of existing issues in the process > > > > > > ### Short maintenance cycles for releases > > > > > > Since we're doing a 3 months release cycle, we are ending with 4 > releases > > > done per year, even though it's more close to 3 releases. > > > > > > There is a high cost to maintain a lot of old releases, backport bug > > fixes, > > > and security patches. In general, we actively support the last 3 minor > > > releases while continuing to develop the next release. E.g., 2.8, 2.9, > > and > > > 2.10, while 2.11 is under development. > > > > > > The result is that a user adopting a particular release is forced to > > > upgrade in a < 1-year timeframe to keep up to date and use a supported > > > release. This timeframe is too short for many users as it imposes a lot > > of > > > forced upgrades, for which they are not prepared in terms of available > > time > > > and required effort. > > > > > > ### Live Upgrade/Downgrade compatibility path > > > > > > In Pulsar, we guarantee that users have a way to do live upgrades and > > > downgrades with zero downtime. > > > > > > This is very powerful because it gives them the freedom to upgrade to a > > new > > > release with the assurance of being able to roll back to the previous > > > release in case any functional or performance regressions are > > encountered. > > > > > > Today, this compatibility is guaranteed across minor versions. Eg: I > can > > do > > > `2.7 -> 2.8 -> 2.7` as a live upgrade. > > > > > > What is not guaranteed is to "skip" releases. E.g.: `2.7 -> 2.9` might > > work > > > or not, but it's not guaranteed. In that case an intermediated upgrade > > > would be required: `2.7 -> 2.8 -> 2.9`. > > > > > > The reasons for which the "skip" upgrade might not work are multiple: > > > 1. Incompatible upgrade of some dependency (e.g., ZooKeeper) that might > > > not be compatible with an older version. > > > 2. Adoption of a new metadata format or data format on disk. > > > Every time we introduce a new incompatible format change (outside of a > > > regular Protobuf field addition), we do it in a 2 steps way: > > > - In a new release, we introduce the new feature/format, disabled by > > > default. The new release can read both old and new formats, though it > > keeps > > > writing the old format by default. > > > - In a subsequent release, we change the default to the new format > > > > > > Note that this consideration is separate from the compatibility between > > > clients and brokers, where we ***never*** break compatibility. The > oldest > > > available Pulsar client can still talk with the newest Pulsar broker, > and > > > vice versa, a new client, will be perfectly fine with an older broker > > > (except the new features won't be working). > > > > > > ### Releases getting delayed > > > > > > Another problem we have been experiencing is that release cycles have > > been > > > stretching considerably. Part of this has been because we have been > > > reaching the end of the release window, preparing a candidate, and then > > > taking a long time to flush out all issues found at the last minute in > > the > > > new release. > > > > > > We need to ensure that we have a date set in stone to deliver the > release > > > to users. > > > > > > ## Proposal > > > > > > The proposal to address the above issues is composed of 2 parts. > > > > > > ### 1. Establish Long Term Support releases > > > > > > We need to provide a way for users to quickly understand the expected > > > lifecycle timeline of a given release and
Re: Force redirect questions from Slack to GitHub Discussions or StackOverflow?
What about such wording? --- Your question was moved here: https://github.com/apache/pulsar/discussions/123 Please consider asking new questions here: * At StackOverflow using apache-pulsar tag. * In the Q category at GitHub Discussions. * Apache Pulsar User Mailing List. It will make it searchable by others. Also, this way we can collect a knowledge base outside of Slack over time. I can’t see how the words “please consider” force the user to do something. Users who have an account on StackOverflow or GitHub can use these platforms next time. Others can send their question via the mailing list. From: Dave Fisher Date: Friday, February 17, 2023 at 9:28 PM To: dev@pulsar.apache.org Subject: Re: Force redirect questions from Slack to GitHub Discussions or StackOverflow? My concern is that users should have a choice on where to post their questions. They might have concerns about GitHub’s terms and conditions. We can pin a message to slack pointing to GitHub discussions and stackoverflow. Best, Dave Sent from my iPhone > On Feb 17, 2023, at 9:22 AM, Kiryl Valkovich > wrote: > > I’m the owner of this account. > The goal is to test drive duplicating Slack questions to the GitHub > discussions. > With the current level of activity in Slack it’s not so hard to do it > manually. > > I’m in CET now. I can share the account credentials with people who can post > questions to GitHub Discussions on behalf of this account in other time zones. > Or I can do it once a day. > > If someone doesn’t find it useful or has ideas on how to do it in a better > way, just say it directly. > > From: Enrico Olivelli > Date: Friday, February 17, 2023 at 3:43 PM > To: dev@pulsar.apache.org > Subject: Re: Force redirect questions from Slack to GitHub Discussions or > StackOverflow? > Hello, > I see that some "Pulsar Community Bot" appeared in Slack > > it is connected to this email address "pulsar.community@gmail.com" > > While I find this thing "amazing"I wonder if I missed something, > who is the owner of this "bot" ? > > > Enrico > >> Il giorno gio 16 feb 2023 alle ore 16:03 Kiryl Valkovich >> ha scritto: >> >> Played with Slack and StackOverflow APIs a bit. >> >> The Slack API works as expected. After clicking the message button, it sends >> a message descriptor to my app where I can do anything with its content. >> >> It’s possible to post messages via the StackOverflow API, but it’s unlikely >> that any Slack message can be converted to a StackOverflow question. >> >> I encountered several types of validation errors: >> >> - This question body does not meet our quality standards. Please >> make sure that it completely describes your problem - including what you >> have already tried - and is written using proper grammar. >> >> * Something similar to “This message looks like a duplicate of another >> message”. >> >> I believe, GitHub Discussions don’t have such kind of “quality standards” >> validation. >> >> From: Kiryl Valkovich >> Date: Thursday, February 16, 2023 at 1:33 PM >> To: dev@pulsar.apache.org >> Subject: Re: Force redirect questions from Slack to GitHub Discussions or >> StackOverflow? >> If there are no hidden obstacles, we can implement it. >> StackOverflow supports question creation using REST API: >> https://api.stackexchange.com/docs/create-question >> >> From: Zike Yang >> Date: Thursday, February 16, 2023 at 11:41 AM >> To: dev@pulsar.apache.org >> Subject: Re: Force redirect questions from Slack to GitHub Discussions or >> StackOverflow? >> +1, That sounds great to me. >> >>> 2. You click the three dots button on his message -> “Convert to a GitHub >>> discussion”. >> >> Is it a similar workflow for converting to a StackOverflow question? >> >> BR, >> Zike Yang >> >>> On Thu, Feb 16, 2023 at 12:14 PM wrote: >>> >>> +1 >>> >>> Since web pages are more easily and public. >>> >>> Best >>> Mattison >>> On Feb 16, 2023, 07:58 +0800, Christophe Bornet , >>> wrote: +100 Also note that for good or bad reasons, the number of questions on StaOverflow is often used as a metric for the popularity of a project. Le mer. 15 févr. 2023 à 13:12, Kiryl Valkovich a écrit : > Hi everyone! Enrico Olivelli asked me to repost it to the mailing list. > > --- Me > I’m very worried that good answers from David Kjerrumgaard and others > won’t be googleable because it’s in Slack. To make any search you need to > pay a monthly subscription. > > In my opinion, it would be wiser to make StackOverflow, Discuss, or GitHub > discussions a place for questions. And strictly redirect people who ask > any > question in Slack to the right place. > In GitHub discussions, you also can manage categories, as well as you can > manage channels in Slack. > > Subscription to a specific category is coming soon. >
Re: Force redirect questions from Slack to GitHub Discussions or StackOverflow?
My concern is that users should have a choice on where to post their questions. They might have concerns about GitHub’s terms and conditions. We can pin a message to slack pointing to GitHub discussions and stackoverflow. Best, Dave Sent from my iPhone > On Feb 17, 2023, at 9:22 AM, Kiryl Valkovich > wrote: > > I’m the owner of this account. > The goal is to test drive duplicating Slack questions to the GitHub > discussions. > With the current level of activity in Slack it’s not so hard to do it > manually. > > I’m in CET now. I can share the account credentials with people who can post > questions to GitHub Discussions on behalf of this account in other time zones. > Or I can do it once a day. > > If someone doesn’t find it useful or has ideas on how to do it in a better > way, just say it directly. > > From: Enrico Olivelli > Date: Friday, February 17, 2023 at 3:43 PM > To: dev@pulsar.apache.org > Subject: Re: Force redirect questions from Slack to GitHub Discussions or > StackOverflow? > Hello, > I see that some "Pulsar Community Bot" appeared in Slack > > it is connected to this email address "pulsar.community@gmail.com" > > While I find this thing "amazing"I wonder if I missed something, > who is the owner of this "bot" ? > > > Enrico > >> Il giorno gio 16 feb 2023 alle ore 16:03 Kiryl Valkovich >> ha scritto: >> >> Played with Slack and StackOverflow APIs a bit. >> >> The Slack API works as expected. After clicking the message button, it sends >> a message descriptor to my app where I can do anything with its content. >> >> It’s possible to post messages via the StackOverflow API, but it’s unlikely >> that any Slack message can be converted to a StackOverflow question. >> >> I encountered several types of validation errors: >> >> - This question body does not meet our quality standards. Please >> make sure that it completely describes your problem - including what you >> have already tried - and is written using proper grammar. >> >> * Something similar to “This message looks like a duplicate of another >> message”. >> >> I believe, GitHub Discussions don’t have such kind of “quality standards” >> validation. >> >> From: Kiryl Valkovich >> Date: Thursday, February 16, 2023 at 1:33 PM >> To: dev@pulsar.apache.org >> Subject: Re: Force redirect questions from Slack to GitHub Discussions or >> StackOverflow? >> If there are no hidden obstacles, we can implement it. >> StackOverflow supports question creation using REST API: >> https://api.stackexchange.com/docs/create-question >> >> From: Zike Yang >> Date: Thursday, February 16, 2023 at 11:41 AM >> To: dev@pulsar.apache.org >> Subject: Re: Force redirect questions from Slack to GitHub Discussions or >> StackOverflow? >> +1, That sounds great to me. >> >>> 2. You click the three dots button on his message -> “Convert to a GitHub >>> discussion”. >> >> Is it a similar workflow for converting to a StackOverflow question? >> >> BR, >> Zike Yang >> >>> On Thu, Feb 16, 2023 at 12:14 PM wrote: >>> >>> +1 >>> >>> Since web pages are more easily and public. >>> >>> Best >>> Mattison >>> On Feb 16, 2023, 07:58 +0800, Christophe Bornet , >>> wrote: +100 Also note that for good or bad reasons, the number of questions on StaOverflow is often used as a metric for the popularity of a project. Le mer. 15 févr. 2023 à 13:12, Kiryl Valkovich a écrit : > Hi everyone! Enrico Olivelli asked me to repost it to the mailing list. > > --- Me > I’m very worried that good answers from David Kjerrumgaard and others > won’t be googleable because it’s in Slack. To make any search you need to > pay a monthly subscription. > > In my opinion, it would be wiser to make StackOverflow, Discuss, or GitHub > discussions a place for questions. And strictly redirect people who ask > any > question in Slack to the right place. > In GitHub discussions, you also can manage categories, as well as you can > manage channels in Slack. > > Subscription to a specific category is coming soon. > https://github.com/community/community/discussions/3951#discussioncomment-3879939 > The most important that it’s searchable. > > Examples: > https://github.com/community/community/discussions > https://github.com/apache/superset/discussions > > --- Later me to David Kjerrumgaard > What do you think about the following workflow: > 1. The user asks a new question in Slack. > 2. You click the three dots button on his message -> “Convert to a GitHub > discussion”. > 3. The bot creates a new GitHub discussion in the “Q” category with the > original message’s content. > 4. The bot converts the original message to a thread and posts a message > like: >>> In order to keep history and make your question searchable by other > Apache Pulsar users, it has been converted to
Re: Force redirect questions from Slack to GitHub Discussions or StackOverflow?
I’m the owner of this account. The goal is to test drive duplicating Slack questions to the GitHub discussions. With the current level of activity in Slack it’s not so hard to do it manually. I’m in CET now. I can share the account credentials with people who can post questions to GitHub Discussions on behalf of this account in other time zones. Or I can do it once a day. If someone doesn’t find it useful or has ideas on how to do it in a better way, just say it directly. From: Enrico Olivelli Date: Friday, February 17, 2023 at 3:43 PM To: dev@pulsar.apache.org Subject: Re: Force redirect questions from Slack to GitHub Discussions or StackOverflow? Hello, I see that some "Pulsar Community Bot" appeared in Slack it is connected to this email address "pulsar.community@gmail.com" While I find this thing "amazing"I wonder if I missed something, who is the owner of this "bot" ? Enrico Il giorno gio 16 feb 2023 alle ore 16:03 Kiryl Valkovich ha scritto: > > Played with Slack and StackOverflow APIs a bit. > > The Slack API works as expected. After clicking the message button, it sends > a message descriptor to my app where I can do anything with its content. > > It’s possible to post messages via the StackOverflow API, but it’s unlikely > that any Slack message can be converted to a StackOverflow question. > > I encountered several types of validation errors: > > - This question body does not meet our quality standards. Please > make sure that it completely describes your problem - including what you have > already tried - and is written using proper grammar. > > * Something similar to “This message looks like a duplicate of another > message”. > > I believe, GitHub Discussions don’t have such kind of “quality standards” > validation. > > From: Kiryl Valkovich > Date: Thursday, February 16, 2023 at 1:33 PM > To: dev@pulsar.apache.org > Subject: Re: Force redirect questions from Slack to GitHub Discussions or > StackOverflow? > If there are no hidden obstacles, we can implement it. > StackOverflow supports question creation using REST API: > https://api.stackexchange.com/docs/create-question > > From: Zike Yang > Date: Thursday, February 16, 2023 at 11:41 AM > To: dev@pulsar.apache.org > Subject: Re: Force redirect questions from Slack to GitHub Discussions or > StackOverflow? > +1, That sounds great to me. > > > 2. You click the three dots button on his message -> “Convert to a GitHub > > discussion”. > > Is it a similar workflow for converting to a StackOverflow question? > > BR, > Zike Yang > > On Thu, Feb 16, 2023 at 12:14 PM wrote: > > > > +1 > > > > Since web pages are more easily and public. > > > > Best > > Mattison > > On Feb 16, 2023, 07:58 +0800, Christophe Bornet , > > wrote: > > > +100 > > > Also note that for good or bad reasons, the number of questions on > > > StaOverflow is often used as a metric for the popularity of a project. > > > > > > Le mer. 15 févr. 2023 à 13:12, Kiryl Valkovich > > > > > > a écrit : > > > > > > > Hi everyone! Enrico Olivelli asked me to repost it to the mailing list. > > > > > > > > --- Me > > > > I’m very worried that good answers from David Kjerrumgaard and others > > > > won’t be googleable because it’s in Slack. To make any search you need > > > > to > > > > pay a monthly subscription. > > > > > > > > In my opinion, it would be wiser to make StackOverflow, Discuss, or > > > > GitHub > > > > discussions a place for questions. And strictly redirect people who ask > > > > any > > > > question in Slack to the right place. > > > > In GitHub discussions, you also can manage categories, as well as you > > > > can > > > > manage channels in Slack. > > > > > > > > Subscription to a specific category is coming soon. > > > > https://github.com/community/community/discussions/3951#discussioncomment-3879939 > > > > The most important that it’s searchable. > > > > > > > > Examples: > > > > https://github.com/community/community/discussions > > > > https://github.com/apache/superset/discussions > > > > > > > > --- Later me to David Kjerrumgaard > > > > What do you think about the following workflow: > > > > 1. The user asks a new question in Slack. > > > > 2. You click the three dots button on his message -> “Convert to a > > > > GitHub > > > > discussion”. > > > > 3. The bot creates a new GitHub discussion in the “Q” category with > > > > the > > > > original message’s content. > > > > 4. The bot converts the original message to a thread and posts a message > > > > like: > > > > > > In order to keep history and make your question searchable by other > > > > Apache Pulsar users, it has been converted to a GitHub discussion. > > > > > > Further conversation is available by this link: > > > > https://github.com/apache/pulsar/discussions/18766. > > > > 5. You answer the question on GitHub. > > > > > > > > How it may work: > > > > https://api.slack.com/best-practices/blueprints/actions-and-dialogs > > > > I can try to implement
Re: Introducer Pulsar admin api to pulsar-client-go
Thank for StreamNative for willing to donate this project. This means we don't have to develop and maintain a set of HTTP code from scratch. My idea aligns with Yunze's, and separating it into a standalone pulsar-admin-go project would be better. The **pulsarctl** repo contains bookkeeper http call too. Maybe we can have a project bookkeeper-admin-go ?（it's a liitle going off-topic ） Thanks ZhangJian He On Fri, 17 Feb 2023 at 20:29, PengHui Li wrote: > Hi Yunze, > > Yes, we can split it. > Both one repo with two modules or two repos works for me. > > The pulsarctl already have the admin API and CLI. > So I think we don’t need to develop another one. > > Best, > Penghui > > > On Feb 17, 2023, at 17:44, Yunze Xu > wrote: > > > > Hi PengHui, > > > > Now I changed my mind a bit. Even if the pulsarctl was contributed to > > the Apache Foundation, I think we should also avoid adding it as the > > dependency. What we need is an API layer but not the CLI, while > > pulsarctl couples the API and CLI. > > > > At the moment, my expectation is: > > 1. Use a separate repo (e.g. pulsar-admin-go) to implement the admin > > APIs in Golang. > > 2. Depend this new repo in pulsarctl. > > > > Then we will have three Go projects: > > - pulsar-client-go: The Pulsar Go client APIs > > - pulsar-admin-go: The Pulsar Go admin APIs > > - pulsarctl: The admin CLI tool written in Go > > > > Thanks, > > Yunze > > > > On Fri, Feb 17, 2023 at 4:22 PM PengHui Li wrote: > >> > >> I checked with Sijie today. > >> StreamNative can contribute the pulsarctl project to Apache Foundation. > >> > >> Regards, > >> Penghui > >> > >> On Fri, Feb 17, 2023 at 4:02 PM Enrico Olivelli > wrote: > >> > >>> I agree to add an admin API to the go client, this would be very > helpful. > >>> > >>> Il giorno ven 17 feb 2023 alle ore 08:44 Zixuan Liu > >>> ha scritto: > > Hi Zhangjian, > > This is a good idea to write the admin client by golang, but I don't > suggest add the admin features to pulsar-go-client, it's better to > use a > new repository to do that to separate dependencies. > > BTW, StreamNative has a pulsarctl [0] tool, which includes the admin > api. > > >> It's better to reuse existing code rather than reinventing the > wheel. > > I aggred this point. If possible, we can integrate the pulsarctl to > this > new project. > >>> > >>> We are talking about adding a client that calls a > >>> well defined and maintained REST API. > >>> It is better to have our implementation and not rely on third parties > >>> when it is possible. > >>> If there is a security issue in pulsarctl, how would we handle that ? > >>> Also the Pulsar community maintains the Pulsar API and this is the > >>> place where it is easier to keep the client up-to-date with the new > >>> APIs that we will develop, > >>> we can't wait for a third party project to implement our own APIs and > >>> wait for an upgrade (even if it is OSS, we cannot cut releases or have > >>> control over the release cycle) > >>> > >>> > >>> Enrico > >>> > >>> > >>> > > [0] - https://github.com/streamnative/pulsarctl > > Thanks, > Zixuan > > > ZhangJian He 于2023年2月17日周五 13:47写道： > > > Separating dependencies is better. For example, I think > >>> Pulsar-admin-go can > > only have golang standard tls and http dependencies. > > But it seems impossible to have two go modules when publishing > packages > > using github. > > > >> Has anyone tried generating an admin client from our generated open > > api spec? > > > > I have attempted it, but it requires us to modify our Swagger file. > Our > > existing Swagger file can't generate HTTP clients directly. Perhaps > we > >>> can > > rewrite a unified and standardized Swagger file, and then generate > all > > code, including brokers, from there gradually. > > > > Thanks > > ZhangJian He > > > > > > On Fri, 17 Feb 2023 at 12:37, Yunze Xu > > > wrote: > > > >>> I notice that the Java Client and the Java Admin Client are > >>> separate > >> dependencies. Is this boundary important to maintain for other > >> language admin clients? > >> > >> IMO, separating them is better to maintain. I had an idea to > >>> implement > >> a pure C implementation of the Pulsar admin API. Only libcurl and > >> openssl dependencies are required. Compared with the C++ library, > the > >> pure C library has smaller size, better ABI compatibility, and much > >> quicker compilation speed than the C++ library, which has some more > >> heavy dependencies like Boost and Protobuf. > >> > >> Thanks, > >> Yunze > >> > >> On Fri, Feb 17, 2023 at 11:58 AM Michael Marshall < > >>> mmarsh...@apache.org> > >> wrote: > >>> > >>> I think it would be valuable to have admin clients in many > >>> languages. > >>> Has anyone tried
Re: Force redirect questions from Slack to GitHub Discussions or StackOverflow?
Hello, I see that some "Pulsar Community Bot" appeared in Slack it is connected to this email address "pulsar.community@gmail.com" While I find this thing "amazing"I wonder if I missed something, who is the owner of this "bot" ? Enrico Il giorno gio 16 feb 2023 alle ore 16:03 Kiryl Valkovich ha scritto: > > Played with Slack and StackOverflow APIs a bit. > > The Slack API works as expected. After clicking the message button, it sends > a message descriptor to my app where I can do anything with its content. > > It’s possible to post messages via the StackOverflow API, but it’s unlikely > that any Slack message can be converted to a StackOverflow question. > > I encountered several types of validation errors: > > - This question body does not meet our quality standards. Please > make sure that it completely describes your problem - including what you have > already tried - and is written using proper grammar. > > * Something similar to “This message looks like a duplicate of another > message”. > > I believe, GitHub Discussions don’t have such kind of “quality standards” > validation. > > From: Kiryl Valkovich > Date: Thursday, February 16, 2023 at 1:33 PM > To: dev@pulsar.apache.org > Subject: Re: Force redirect questions from Slack to GitHub Discussions or > StackOverflow? > If there are no hidden obstacles, we can implement it. > StackOverflow supports question creation using REST API: > https://api.stackexchange.com/docs/create-question > > From: Zike Yang > Date: Thursday, February 16, 2023 at 11:41 AM > To: dev@pulsar.apache.org > Subject: Re: Force redirect questions from Slack to GitHub Discussions or > StackOverflow? > +1, That sounds great to me. > > > 2. You click the three dots button on his message -> “Convert to a GitHub > > discussion”. > > Is it a similar workflow for converting to a StackOverflow question? > > BR, > Zike Yang > > On Thu, Feb 16, 2023 at 12:14 PM wrote: > > > > +1 > > > > Since web pages are more easily and public. > > > > Best > > Mattison > > On Feb 16, 2023, 07:58 +0800, Christophe Bornet , > > wrote: > > > +100 > > > Also note that for good or bad reasons, the number of questions on > > > StaOverflow is often used as a metric for the popularity of a project. > > > > > > Le mer. 15 févr. 2023 à 13:12, Kiryl Valkovich > > > > > > a écrit : > > > > > > > Hi everyone! Enrico Olivelli asked me to repost it to the mailing list. > > > > > > > > --- Me > > > > I’m very worried that good answers from David Kjerrumgaard and others > > > > won’t be googleable because it’s in Slack. To make any search you need > > > > to > > > > pay a monthly subscription. > > > > > > > > In my opinion, it would be wiser to make StackOverflow, Discuss, or > > > > GitHub > > > > discussions a place for questions. And strictly redirect people who ask > > > > any > > > > question in Slack to the right place. > > > > In GitHub discussions, you also can manage categories, as well as you > > > > can > > > > manage channels in Slack. > > > > > > > > Subscription to a specific category is coming soon. > > > > https://github.com/community/community/discussions/3951#discussioncomment-3879939 > > > > The most important that it’s searchable. > > > > > > > > Examples: > > > > https://github.com/community/community/discussions > > > > https://github.com/apache/superset/discussions > > > > > > > > --- Later me to David Kjerrumgaard > > > > What do you think about the following workflow: > > > > 1. The user asks a new question in Slack. > > > > 2. You click the three dots button on his message -> “Convert to a > > > > GitHub > > > > discussion”. > > > > 3. The bot creates a new GitHub discussion in the “Q” category with > > > > the > > > > original message’s content. > > > > 4. The bot converts the original message to a thread and posts a message > > > > like: > > > > > > In order to keep history and make your question searchable by other > > > > Apache Pulsar users, it has been converted to a GitHub discussion. > > > > > > Further conversation is available by this link: > > > > https://github.com/apache/pulsar/discussions/18766. > > > > 5. You answer the question on GitHub. > > > > > > > > How it may work: > > > > https://api.slack.com/best-practices/blueprints/actions-and-dialogs > > > > I can try to implement it makes any sense for you. (edited) > > > > > > > > Full original thread: > > > > https://apache-pulsar.slack.com/archives/C5Z4T36F7/p1676449603034309 > > > > > > > >
Re: Introducer Pulsar admin api to pulsar-client-go
Hi Yunze, Yes, we can split it. Both one repo with two modules or two repos works for me. The pulsarctl already have the admin API and CLI. So I think we don’t need to develop another one. Best, Penghui > On Feb 17, 2023, at 17:44, Yunze Xu wrote: > > Hi PengHui, > > Now I changed my mind a bit. Even if the pulsarctl was contributed to > the Apache Foundation, I think we should also avoid adding it as the > dependency. What we need is an API layer but not the CLI, while > pulsarctl couples the API and CLI. > > At the moment, my expectation is: > 1. Use a separate repo (e.g. pulsar-admin-go) to implement the admin > APIs in Golang. > 2. Depend this new repo in pulsarctl. > > Then we will have three Go projects: > - pulsar-client-go: The Pulsar Go client APIs > - pulsar-admin-go: The Pulsar Go admin APIs > - pulsarctl: The admin CLI tool written in Go > > Thanks, > Yunze > > On Fri, Feb 17, 2023 at 4:22 PM PengHui Li wrote: >> >> I checked with Sijie today. >> StreamNative can contribute the pulsarctl project to Apache Foundation. >> >> Regards, >> Penghui >> >> On Fri, Feb 17, 2023 at 4:02 PM Enrico Olivelli wrote: >> >>> I agree to add an admin API to the go client, this would be very helpful. >>> >>> Il giorno ven 17 feb 2023 alle ore 08:44 Zixuan Liu >>> ha scritto: Hi Zhangjian, This is a good idea to write the admin client by golang, but I don't suggest add the admin features to pulsar-go-client, it's better to use a new repository to do that to separate dependencies. BTW, StreamNative has a pulsarctl [0] tool, which includes the admin api. >> It's better to reuse existing code rather than reinventing the wheel. I aggred this point. If possible, we can integrate the pulsarctl to this new project. >>> >>> We are talking about adding a client that calls a >>> well defined and maintained REST API. >>> It is better to have our implementation and not rely on third parties >>> when it is possible. >>> If there is a security issue in pulsarctl, how would we handle that ? >>> Also the Pulsar community maintains the Pulsar API and this is the >>> place where it is easier to keep the client up-to-date with the new >>> APIs that we will develop, >>> we can't wait for a third party project to implement our own APIs and >>> wait for an upgrade (even if it is OSS, we cannot cut releases or have >>> control over the release cycle) >>> >>> >>> Enrico >>> >>> >>> [0] - https://github.com/streamnative/pulsarctl Thanks, Zixuan ZhangJian He 于2023年2月17日周五 13:47写道： > Separating dependencies is better. For example, I think >>> Pulsar-admin-go can > only have golang standard tls and http dependencies. > But it seems impossible to have two go modules when publishing packages > using github. > >> Has anyone tried generating an admin client from our generated open > api spec? > > I have attempted it, but it requires us to modify our Swagger file. Our > existing Swagger file can't generate HTTP clients directly. Perhaps we >>> can > rewrite a unified and standardized Swagger file, and then generate all > code, including brokers, from there gradually. > > Thanks > ZhangJian He > > > On Fri, 17 Feb 2023 at 12:37, Yunze Xu > wrote: > >>> I notice that the Java Client and the Java Admin Client are >>> separate >> dependencies. Is this boundary important to maintain for other >> language admin clients? >> >> IMO, separating them is better to maintain. I had an idea to >>> implement >> a pure C implementation of the Pulsar admin API. Only libcurl and >> openssl dependencies are required. Compared with the C++ library, the >> pure C library has smaller size, better ABI compatibility, and much >> quicker compilation speed than the C++ library, which has some more >> heavy dependencies like Boost and Protobuf. >> >> Thanks, >> Yunze >> >> On Fri, Feb 17, 2023 at 11:58 AM Michael Marshall < >>> mmarsh...@apache.org> >> wrote: >>> >>> I think it would be valuable to have admin clients in many >>> languages. >>> Has anyone tried generating an admin client from our generated open >>> api spec? >>> >>> I notice that the Java Client and the Java Admin Client are >>> separate >>> dependencies. Is this boundary important to maintain for other >>> language admin clients? >>> >>> Thanks, >>> Michael >>> >>> On Thu, Feb 16, 2023 at 7:47 PM ZhangJian He > wrote: I would like to express that the current Pulsar client for Go (pulsar-client-go) is missing the pulsar Admin API. As such, I >>> would >> like to propose that we work towards adding this feature to >> pulsar-client-go. I believe that this new feature would be a valuable
[VOTE] Pulsar Client Python Release 3.1.0 Candidate 3
This is the 3rd release candidate for Apache Pulsar Client Python, version 3.1.0. It fixes the following issues: https://github.com/apache/pulsar-client-python/milestone/2?closed=1 *** Please download, test and vote on this release. This vote will stay open for at least 72 hours *** Python wheels: https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-python-3.1.0-candidate-3/ The supported python versions are 3.7, 3.8, 3.9, 3.10 and 3.11. The supported platforms and architectures are: - Windows x86_64 (windows/) - glibc-based Linux x86_64 (linux-glibc-x86_64/) - glibc-based Linux arm64 (linux-glibc-arm64/) - musl-based Linux x86_64 (linux-musl-x86_64/) - musl-based Linux arm64 (linux-musl-arm64/) - macOS universal 2 (macos/) You can download the wheel (the `.whl` file) according to your own OS and Python version and install the wheel: - Windows: `py -m pip install *.whl --force-reinstall` - Linux or macOS: `python3 -m pip install *.whl --force-reinstall` The tag to be voted upon: v3.1.0-candidate-3 (9ed92ecee632c42b81a3198b8824d70d080af7f0) https://github.com/apache/pulsar-client-python/releases/tag/v3.1.0-candidate-3 Pulsar's KEYS file containing PGP keys you use to sign the release: https://dist.apache.org/repos/dist/release/pulsar/KEYS Please download the Python wheels and follow the README to test.
[VOTE] Pulsar Node.js Client Release 1.8.1 Candidate 1
Hi everyone, This is the first release candidate for Apache Pulsar Node.js client, version 1.8.1. It fixes the following issues:https://github.com/apache/pulsar-client-node/pulls?q=is%3Apr+label%3Arelease%2Fv1.8.1+is%3Aclosed Please download the source files and review this release candidate: - Download the source package, verify shasum and asc - Follow the README.md to build and run the Pulsar Node.js client. The release candidate package has been published to the npm registry:https://www.npmjs.com/package/pulsar-client/v/1.8.1-rc.1 You can install it by `npm i pulsar-client@1.8.1-rc.1 --pulsar_binary_host_mirror=https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-node/` and verify the package. The vote will be open for at least 72 hours. It is adopted by majority approval, with at least 3 PMC affirmative votes. Source files:https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-node/pulsar-client-node-1.8.1-rc.1/ Pulsar's KEYS file containing PGP keys we use to sign the release:https://dist.apache.org/repos/dist/dev/pulsar/KEYS SHA-512 checksum: ed89b4ad467d3cb75ed37096b35d91b872cd93d36cd953512fc7edcb75dbac5162592f6f51b5ab08f26b3dca1c57a3d3fe7a5e4f109551c66943a5b09392d51a apache-pulsar-client-node-1.8.1.tar.gz The tag to be voted upon: v1.8.1-rc.1(3e843f0)https://github.com/apache/pulsar-client-node/releases/tag/v1.8.1-rc.1 Please review and vote on the release candidate #1 for the version 1.8.1, as follows: [ ] +1, Approve the release [ ] -1, Do not approve the release (please provide specific comments) Thanks, Baodi Shi
Re: Inconsistent GPG keys in dev and release repositories
> Actually we shouldn't have a "dev" KEYS file. It is confusing. Make sense to me. Thanks, Zike Yang Zike Yang On Fri, Feb 17, 2023 at 5:37 PM Yunze Xu wrote: > > I've synchronized the missed keys from dev to release, including the > following committers: > - Yunze Xu > - Yuto Furuta > - xiangying > - Baodi Shi > > See https://dist.apache.org/repos/dist/release/pulsar/KEYS > > Regarding whether to drop the KEYS in the dev repo, let's wait more opinions. > > Thanks, > Yunze > > On Fri, Feb 17, 2023 at 5:04 PM Yunze Xu wrote: > > > > > When a new committer wants to cut a release they can ask for help to > > the PMC to add their KEY to the "release" KEYS > > > > I agree. We should only allow a PMC member to update the key. > > > > > Seems that you didn't add your public key here [0]. > > > > Yes, I found this issue as well, my key is only added to the dev repo. > > > > I will add the missed keys to the release repo. > > > > Thanks, > > Yunze > > > > On Fri, Feb 17, 2023 at 4:52 PM Zike Yang wrote: > > > > > > Hi, Yunze > > > > > > Seems that you didn't add your public key here [0]. There is an issue > > > when verifying the Pulsar C++ Client 3.1.2 released files: > > > ``` > > > ➜ pulsar-archive gpg --verify apache-pulsar-client-cpp-3.1.2.tar.gz.asc > > > gpg: assuming signed data in 'apache-pulsar-client-cpp-3.1.2.tar.gz' > > > gpg: Signature made 三 2/ 8 16:05:49 2023 CST > > > gpg:using RSA key 9FE9B4F8A2DFD44891CBA27442BB6AFB6CD26FA6 > > > gpg: Can't check signature: No public key > > > ``` > > > > > > I think you need to upload your kesy to [1]. > > > > > > [0] https://archive.apache.org/dist/pulsar/KEYS > > > [1] https://dist.apache.org/repos/dist/release/pulsar/KEYS > > > > > > BR, > > > Zike Yang > > > > > > On Fri, Feb 17, 2023 at 4:22 PM Yunze Xu > > > wrote: > > > > > > > > Oh that's right. Then we have to update one of them. > > > > > > > > Thanks, > > > > Yunze > > > > > > > > On Fri, Feb 17, 2023 at 3:02 PM Zike Yang wrote: > > > > > > > > > > Hi, Yunze > > > > > > > > > > I think the KEYS file in the release repo is necessary. They are both > > > > > used to verify the release file. Otherwise, the user will fail when > > > > > checking the GPG signature on the release file. > > > > > > > > > > BR, > > > > > Zike Yang > > > > > > > > > > On Fri, Feb 17, 2023 at 2:16 PM Yunze Xu > > > > > wrote: > > > > > > > > > > > > Hi all, > > > > > > > > > > > > I found the GPG keys, which are used in verifying the signatures of > > > > > > release candidates, are much different in dev and release > > > > > > repositories: > > > > > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS > > > > > > https://dist.apache.org/repos/dist/release/pulsar/KEYS > > > > > > > > > > > > From here [1], it seems like we need to append the GPG key of a > > > > > > committer into the release repo as well. But it seems that the KEYS > > > > > > file in the release repo is never used. Should we make them > > > > > > consistent? Or just remove the KEYS file in release repo? > > > > > > > > > > > > [1] > > > > > > https://pulsar.apache.org/contribute/create-gpg-keys/#appending-the-key-to-keys-files
[ANNOUNCE] Apache Pulsar Client C++ 3.1.2 released
The Apache Pulsar team is proud to announce Apache Pulsar Client C++ version 3.1.2. Pulsar is a highly scalable, low latency messaging platform running on commodity hardware. It provides simple pub-sub semantics over topics, guaranteed at-least-once delivery of messages, automatic cursor management for subscribers, and cross-datacenter replication. For Pulsar release details and downloads, visit: https://pulsar.apache.org/download Release Notes are at: https://pulsar.apache.org/release-notes We would like to thank the contributors that made the release possible. Regards, The Pulsar Team
Re: Introducer Pulsar admin api to pulsar-client-go
Hi PengHui, Now I changed my mind a bit. Even if the pulsarctl was contributed to the Apache Foundation, I think we should also avoid adding it as the dependency. What we need is an API layer but not the CLI, while pulsarctl couples the API and CLI. At the moment, my expectation is: 1. Use a separate repo (e.g. pulsar-admin-go) to implement the admin APIs in Golang. 2. Depend this new repo in pulsarctl. Then we will have three Go projects: - pulsar-client-go: The Pulsar Go client APIs - pulsar-admin-go: The Pulsar Go admin APIs - pulsarctl: The admin CLI tool written in Go Thanks, Yunze On Fri, Feb 17, 2023 at 4:22 PM PengHui Li wrote: > > I checked with Sijie today. > StreamNative can contribute the pulsarctl project to Apache Foundation. > > Regards, > Penghui > > On Fri, Feb 17, 2023 at 4:02 PM Enrico Olivelli wrote: > > > I agree to add an admin API to the go client, this would be very helpful. > > > > Il giorno ven 17 feb 2023 alle ore 08:44 Zixuan Liu > > ha scritto: > > > > > > Hi Zhangjian, > > > > > > This is a good idea to write the admin client by golang, but I don't > > > suggest add the admin features to pulsar-go-client, it's better to use a > > > new repository to do that to separate dependencies. > > > > > > BTW, StreamNative has a pulsarctl [0] tool, which includes the admin api. > > > > > > > > It's better to reuse existing code rather than reinventing the wheel. > > > > > > I aggred this point. If possible, we can integrate the pulsarctl to this > > > new project. > > > > We are talking about adding a client that calls a > > well defined and maintained REST API. > > It is better to have our implementation and not rely on third parties > > when it is possible. > > If there is a security issue in pulsarctl, how would we handle that ? > > Also the Pulsar community maintains the Pulsar API and this is the > > place where it is easier to keep the client up-to-date with the new > > APIs that we will develop, > > we can't wait for a third party project to implement our own APIs and > > wait for an upgrade (even if it is OSS, we cannot cut releases or have > > control over the release cycle) > > > > > > Enrico > > > > > > > > > > > > [0] - https://github.com/streamnative/pulsarctl > > > > > > Thanks, > > > Zixuan > > > > > > > > > ZhangJian He 于2023年2月17日周五 13:47写道： > > > > > > > Separating dependencies is better. For example, I think > > Pulsar-admin-go can > > > > only have golang standard tls and http dependencies. > > > > But it seems impossible to have two go modules when publishing packages > > > > using github. > > > > > > > > > Has anyone tried generating an admin client from our generated open > > > > api spec? > > > > > > > > I have attempted it, but it requires us to modify our Swagger file. Our > > > > existing Swagger file can't generate HTTP clients directly. Perhaps we > > can > > > > rewrite a unified and standardized Swagger file, and then generate all > > > > code, including brokers, from there gradually. > > > > > > > > Thanks > > > > ZhangJian He > > > > > > > > > > > > On Fri, 17 Feb 2023 at 12:37, Yunze Xu > > > > wrote: > > > > > > > > > > I notice that the Java Client and the Java Admin Client are > > separate > > > > > dependencies. Is this boundary important to maintain for other > > > > > language admin clients? > > > > > > > > > > IMO, separating them is better to maintain. I had an idea to > > implement > > > > > a pure C implementation of the Pulsar admin API. Only libcurl and > > > > > openssl dependencies are required. Compared with the C++ library, the > > > > > pure C library has smaller size, better ABI compatibility, and much > > > > > quicker compilation speed than the C++ library, which has some more > > > > > heavy dependencies like Boost and Protobuf. > > > > > > > > > > Thanks, > > > > > Yunze > > > > > > > > > > On Fri, Feb 17, 2023 at 11:58 AM Michael Marshall < > > mmarsh...@apache.org> > > > > > wrote: > > > > > > > > > > > > I think it would be valuable to have admin clients in many > > languages. > > > > > > Has anyone tried generating an admin client from our generated open > > > > > > api spec? > > > > > > > > > > > > I notice that the Java Client and the Java Admin Client are > > separate > > > > > > dependencies. Is this boundary important to maintain for other > > > > > > language admin clients? > > > > > > > > > > > > Thanks, > > > > > > Michael > > > > > > > > > > > > On Thu, Feb 16, 2023 at 7:47 PM ZhangJian He > > > > wrote: > > > > > > > > > > > > > > I would like to express that the current Pulsar client for Go > > > > > > > (pulsar-client-go) is missing the pulsar Admin API. As such, I > > would > > > > > like > > > > > > > to propose that we work towards adding this feature to > > > > > pulsar-client-go. > > > > > > > > > > > > > > I believe that this new feature would be a valuable addition to > > > > > > > pulsar-client-go, and I am excited to work to make it happen. > > > > > > > > > > > > > > I have submitted a PR: > >
Re: Inconsistent GPG keys in dev and release repositories
I've synchronized the missed keys from dev to release, including the following committers: - Yunze Xu - Yuto Furuta - xiangying - Baodi Shi See https://dist.apache.org/repos/dist/release/pulsar/KEYS Regarding whether to drop the KEYS in the dev repo, let's wait more opinions. Thanks, Yunze On Fri, Feb 17, 2023 at 5:04 PM Yunze Xu wrote: > > > When a new committer wants to cut a release they can ask for help to > the PMC to add their KEY to the "release" KEYS > > I agree. We should only allow a PMC member to update the key. > > > Seems that you didn't add your public key here [0]. > > Yes, I found this issue as well, my key is only added to the dev repo. > > I will add the missed keys to the release repo. > > Thanks, > Yunze > > On Fri, Feb 17, 2023 at 4:52 PM Zike Yang wrote: > > > > Hi, Yunze > > > > Seems that you didn't add your public key here [0]. There is an issue > > when verifying the Pulsar C++ Client 3.1.2 released files: > > ``` > > ➜ pulsar-archive gpg --verify apache-pulsar-client-cpp-3.1.2.tar.gz.asc > > gpg: assuming signed data in 'apache-pulsar-client-cpp-3.1.2.tar.gz' > > gpg: Signature made 三 2/ 8 16:05:49 2023 CST > > gpg:using RSA key 9FE9B4F8A2DFD44891CBA27442BB6AFB6CD26FA6 > > gpg: Can't check signature: No public key > > ``` > > > > I think you need to upload your kesy to [1]. > > > > [0] https://archive.apache.org/dist/pulsar/KEYS > > [1] https://dist.apache.org/repos/dist/release/pulsar/KEYS > > > > BR, > > Zike Yang > > > > On Fri, Feb 17, 2023 at 4:22 PM Yunze Xu > > wrote: > > > > > > Oh that's right. Then we have to update one of them. > > > > > > Thanks, > > > Yunze > > > > > > On Fri, Feb 17, 2023 at 3:02 PM Zike Yang wrote: > > > > > > > > Hi, Yunze > > > > > > > > I think the KEYS file in the release repo is necessary. They are both > > > > used to verify the release file. Otherwise, the user will fail when > > > > checking the GPG signature on the release file. > > > > > > > > BR, > > > > Zike Yang > > > > > > > > On Fri, Feb 17, 2023 at 2:16 PM Yunze Xu > > > > wrote: > > > > > > > > > > Hi all, > > > > > > > > > > I found the GPG keys, which are used in verifying the signatures of > > > > > release candidates, are much different in dev and release > > > > > repositories: > > > > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS > > > > > https://dist.apache.org/repos/dist/release/pulsar/KEYS > > > > > > > > > > From here [1], it seems like we need to append the GPG key of a > > > > > committer into the release repo as well. But it seems that the KEYS > > > > > file in the release repo is never used. Should we make them > > > > > consistent? Or just remove the KEYS file in release repo? > > > > > > > > > > [1] > > > > > https://pulsar.apache.org/contribute/create-gpg-keys/#appending-the-key-to-keys-files
Re: Inconsistent GPG keys in dev and release repositories
> When a new committer wants to cut a release they can ask for help to the PMC to add their KEY to the "release" KEYS I agree. We should only allow a PMC member to update the key. > Seems that you didn't add your public key here [0]. Yes, I found this issue as well, my key is only added to the dev repo. I will add the missed keys to the release repo. Thanks, Yunze On Fri, Feb 17, 2023 at 4:52 PM Zike Yang wrote: > > Hi, Yunze > > Seems that you didn't add your public key here [0]. There is an issue > when verifying the Pulsar C++ Client 3.1.2 released files: > ``` > ➜ pulsar-archive gpg --verify apache-pulsar-client-cpp-3.1.2.tar.gz.asc > gpg: assuming signed data in 'apache-pulsar-client-cpp-3.1.2.tar.gz' > gpg: Signature made 三 2/ 8 16:05:49 2023 CST > gpg:using RSA key 9FE9B4F8A2DFD44891CBA27442BB6AFB6CD26FA6 > gpg: Can't check signature: No public key > ``` > > I think you need to upload your kesy to [1]. > > [0] https://archive.apache.org/dist/pulsar/KEYS > [1] https://dist.apache.org/repos/dist/release/pulsar/KEYS > > BR, > Zike Yang > > On Fri, Feb 17, 2023 at 4:22 PM Yunze Xu wrote: > > > > Oh that's right. Then we have to update one of them. > > > > Thanks, > > Yunze > > > > On Fri, Feb 17, 2023 at 3:02 PM Zike Yang wrote: > > > > > > Hi, Yunze > > > > > > I think the KEYS file in the release repo is necessary. They are both > > > used to verify the release file. Otherwise, the user will fail when > > > checking the GPG signature on the release file. > > > > > > BR, > > > Zike Yang > > > > > > On Fri, Feb 17, 2023 at 2:16 PM Yunze Xu > > > wrote: > > > > > > > > Hi all, > > > > > > > > I found the GPG keys, which are used in verifying the signatures of > > > > release candidates, are much different in dev and release > > > > repositories: > > > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS > > > > https://dist.apache.org/repos/dist/release/pulsar/KEYS > > > > > > > > From here [1], it seems like we need to append the GPG key of a > > > > committer into the release repo as well. But it seems that the KEYS > > > > file in the release repo is never used. Should we make them > > > > consistent? Or just remove the KEYS file in release repo? > > > > > > > > [1] > > > > https://pulsar.apache.org/contribute/create-gpg-keys/#appending-the-key-to-keys-files
Re: Inconsistent GPG keys in dev and release repositories
Hi, Yunze Seems that you didn't add your public key here [0]. There is an issue when verifying the Pulsar C++ Client 3.1.2 released files: ``` ➜ pulsar-archive gpg --verify apache-pulsar-client-cpp-3.1.2.tar.gz.asc gpg: assuming signed data in 'apache-pulsar-client-cpp-3.1.2.tar.gz' gpg: Signature made 三 2/ 8 16:05:49 2023 CST gpg:using RSA key 9FE9B4F8A2DFD44891CBA27442BB6AFB6CD26FA6 gpg: Can't check signature: No public key ``` I think you need to upload your kesy to [1]. [0] https://archive.apache.org/dist/pulsar/KEYS [1] https://dist.apache.org/repos/dist/release/pulsar/KEYS BR, Zike Yang On Fri, Feb 17, 2023 at 4:22 PM Yunze Xu wrote: > > Oh that's right. Then we have to update one of them. > > Thanks, > Yunze > > On Fri, Feb 17, 2023 at 3:02 PM Zike Yang wrote: > > > > Hi, Yunze > > > > I think the KEYS file in the release repo is necessary. They are both > > used to verify the release file. Otherwise, the user will fail when > > checking the GPG signature on the release file. > > > > BR, > > Zike Yang > > > > On Fri, Feb 17, 2023 at 2:16 PM Yunze Xu > > wrote: > > > > > > Hi all, > > > > > > I found the GPG keys, which are used in verifying the signatures of > > > release candidates, are much different in dev and release > > > repositories: > > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS > > > https://dist.apache.org/repos/dist/release/pulsar/KEYS > > > > > > From here [1], it seems like we need to append the GPG key of a > > > committer into the release repo as well. But it seems that the KEYS > > > file in the release repo is never used. Should we make them > > > consistent? Or just remove the KEYS file in release repo? > > > > > > [1] > > > https://pulsar.apache.org/contribute/create-gpg-keys/#appending-the-key-to-keys-files
Re: Inconsistent GPG keys in dev and release repositories
Actually we shouldn't have a "dev" KEYS file. It is confusing. I suggest dropping it. When a new committer wants to cut a release they can ask for help to the PMC to add their KEY to the "release" KEYS Enrico Il giorno ven 17 feb 2023 alle ore 09:21 Yunze Xu ha scritto: > > Oh that's right. Then we have to update one of them. > > Thanks, > Yunze > > On Fri, Feb 17, 2023 at 3:02 PM Zike Yang wrote: > > > > Hi, Yunze > > > > I think the KEYS file in the release repo is necessary. They are both > > used to verify the release file. Otherwise, the user will fail when > > checking the GPG signature on the release file. > > > > BR, > > Zike Yang > > > > On Fri, Feb 17, 2023 at 2:16 PM Yunze Xu > > wrote: > > > > > > Hi all, > > > > > > I found the GPG keys, which are used in verifying the signatures of > > > release candidates, are much different in dev and release > > > repositories: > > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS > > > https://dist.apache.org/repos/dist/release/pulsar/KEYS > > > > > > From here [1], it seems like we need to append the GPG key of a > > > committer into the release repo as well. But it seems that the KEYS > > > file in the release repo is never used. Should we make them > > > consistent? Or just remove the KEYS file in release repo? > > > > > > [1] > > > https://pulsar.apache.org/contribute/create-gpg-keys/#appending-the-key-to-keys-files
Re: Introducer Pulsar admin api to pulsar-client-go
I checked with Sijie today.
StreamNative can contribute the pulsarctl project to Apache Foundation.
Regards,
Penghui
On Fri, Feb 17, 2023 at 4:02 PM Enrico Olivelli wrote:
> I agree to add an admin API to the go client, this would be very helpful.
>
> Il giorno ven 17 feb 2023 alle ore 08:44 Zixuan Liu
> ha scritto:
> >
> > Hi Zhangjian,
> >
> > This is a good idea to write the admin client by golang, but I don't
> > suggest add the admin features to pulsar-go-client, it's better to use a
> > new repository to do that to separate dependencies.
> >
> > BTW, StreamNative has a pulsarctl [0] tool, which includes the admin api.
> >
> > > > It's better to reuse existing code rather than reinventing the wheel.
> >
> > I aggred this point. If possible, we can integrate the pulsarctl to this
> > new project.
>
> We are talking about adding a client that calls a
> well defined and maintained REST API.
> It is better to have our implementation and not rely on third parties
> when it is possible.
> If there is a security issue in pulsarctl, how would we handle that ?
> Also the Pulsar community maintains the Pulsar API and this is the
> place where it is easier to keep the client up-to-date with the new
> APIs that we will develop,
> we can't wait for a third party project to implement our own APIs and
> wait for an upgrade (even if it is OSS, we cannot cut releases or have
> control over the release cycle)
>
>
> Enrico
>
>
>
> >
> > [0] - https://github.com/streamnative/pulsarctl
> >
> > Thanks,
> > Zixuan
> >
> >
> > ZhangJian He 于2023年2月17日周五 13:47写道：
> >
> > > Separating dependencies is better. For example, I think
> Pulsar-admin-go can
> > > only have golang standard tls and http dependencies.
> > > But it seems impossible to have two go modules when publishing packages
> > > using github.
> > >
> > > > Has anyone tried generating an admin client from our generated open
> > > api spec?
> > >
> > > I have attempted it, but it requires us to modify our Swagger file. Our
> > > existing Swagger file can't generate HTTP clients directly. Perhaps we
> can
> > > rewrite a unified and standardized Swagger file, and then generate all
> > > code, including brokers, from there gradually.
> > >
> > > Thanks
> > > ZhangJian He
> > >
> > >
> > > On Fri, 17 Feb 2023 at 12:37, Yunze Xu
> > > wrote:
> > >
> > > > > I notice that the Java Client and the Java Admin Client are
> separate
> > > > dependencies. Is this boundary important to maintain for other
> > > > language admin clients?
> > > >
> > > > IMO, separating them is better to maintain. I had an idea to
> implement
> > > > a pure C implementation of the Pulsar admin API. Only libcurl and
> > > > openssl dependencies are required. Compared with the C++ library, the
> > > > pure C library has smaller size, better ABI compatibility, and much
> > > > quicker compilation speed than the C++ library, which has some more
> > > > heavy dependencies like Boost and Protobuf.
> > > >
> > > > Thanks,
> > > > Yunze
> > > >
> > > > On Fri, Feb 17, 2023 at 11:58 AM Michael Marshall <
> mmarsh...@apache.org>
> > > > wrote:
> > > > >
> > > > > I think it would be valuable to have admin clients in many
> languages.
> > > > > Has anyone tried generating an admin client from our generated open
> > > > > api spec?
> > > > >
> > > > > I notice that the Java Client and the Java Admin Client are
> separate
> > > > > dependencies. Is this boundary important to maintain for other
> > > > > language admin clients?
> > > > >
> > > > > Thanks,
> > > > > Michael
> > > > >
> > > > > On Thu, Feb 16, 2023 at 7:47 PM ZhangJian He
> > > wrote:
> > > > > >
> > > > > > I would like to express that the current Pulsar client for Go
> > > > > > (pulsar-client-go) is missing the pulsar Admin API. As such, I
> would
> > > > like
> > > > > > to propose that we work towards adding this feature to
> > > > pulsar-client-go.
> > > > > >
> > > > > > I believe that this new feature would be a valuable addition to
> > > > > > pulsar-client-go, and I am excited to work to make it happen.
> > > > > >
> > > > > > I have submitted a PR:
> > > > https://github.com/apache/pulsar-client-go/pull/959
> > > > > > The full api is not currently available, but we are adding.
> > > > > >
> > > > > > Below is a simple example about how to use
> > > > > >
> > > > > > ## usage
> > > > > >
> > > > > > ```go
> > > > > > package main
> > > > > >
> > > > > > import (
> > > > > > "fmt"
> > > > > > "github.com/apache/pulsar-client-go/padmin"
> > > > > > )
> > > > > >
> > > > > > func main() {
> > > > > > admin, err := padmin.NewDefaultPulsarAdmin()
> > > > > > if err != nil {
> > > > > > panic(err)
> > > > > > }
> > > > > > // get namespace topic list
> > > > > > topics, err :=
> admin.PersistentTopics.ListNamespaceTopics("tenant",
> > > > > > "namespace")
> > > > > > if err != nil {
> > > > > > panic(err)
> > > > > > }
> > > > > > fmt.Println(topics)
> > > > > > }
> > > > > > ```
> > > > > >
> > > > > > Thanks
> > > > > > ZhangJian
Re: Inconsistent GPG keys in dev and release repositories
Oh that's right. Then we have to update one of them. Thanks, Yunze On Fri, Feb 17, 2023 at 3:02 PM Zike Yang wrote: > > Hi, Yunze > > I think the KEYS file in the release repo is necessary. They are both > used to verify the release file. Otherwise, the user will fail when > checking the GPG signature on the release file. > > BR, > Zike Yang > > On Fri, Feb 17, 2023 at 2:16 PM Yunze Xu wrote: > > > > Hi all, > > > > I found the GPG keys, which are used in verifying the signatures of > > release candidates, are much different in dev and release > > repositories: > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS > > https://dist.apache.org/repos/dist/release/pulsar/KEYS > > > > From here [1], it seems like we need to append the GPG key of a > > committer into the release repo as well. But it seems that the KEYS > > file in the release repo is never used. Should we make them > > consistent? Or just remove the KEYS file in release repo? > > > > [1] > > https://pulsar.apache.org/contribute/create-gpg-keys/#appending-the-key-to-keys-files
Re: Introducer Pulsar admin api to pulsar-client-go
I agree to add an admin API to the go client, this would be very helpful.
Il giorno ven 17 feb 2023 alle ore 08:44 Zixuan Liu
ha scritto:
>
> Hi Zhangjian,
>
> This is a good idea to write the admin client by golang, but I don't
> suggest add the admin features to pulsar-go-client, it's better to use a
> new repository to do that to separate dependencies.
>
> BTW, StreamNative has a pulsarctl [0] tool, which includes the admin api.
>
> > > It's better to reuse existing code rather than reinventing the wheel.
>
> I aggred this point. If possible, we can integrate the pulsarctl to this
> new project.
We are talking about adding a client that calls a
well defined and maintained REST API.
It is better to have our implementation and not rely on third parties
when it is possible.
If there is a security issue in pulsarctl, how would we handle that ?
Also the Pulsar community maintains the Pulsar API and this is the
place where it is easier to keep the client up-to-date with the new
APIs that we will develop,
we can't wait for a third party project to implement our own APIs and
wait for an upgrade (even if it is OSS, we cannot cut releases or have
control over the release cycle)
Enrico
>
> [0] - https://github.com/streamnative/pulsarctl
>
> Thanks,
> Zixuan
>
>
> ZhangJian He 于2023年2月17日周五 13:47写道：
>
> > Separating dependencies is better. For example, I think Pulsar-admin-go can
> > only have golang standard tls and http dependencies.
> > But it seems impossible to have two go modules when publishing packages
> > using github.
> >
> > > Has anyone tried generating an admin client from our generated open
> > api spec?
> >
> > I have attempted it, but it requires us to modify our Swagger file. Our
> > existing Swagger file can't generate HTTP clients directly. Perhaps we can
> > rewrite a unified and standardized Swagger file, and then generate all
> > code, including brokers, from there gradually.
> >
> > Thanks
> > ZhangJian He
> >
> >
> > On Fri, 17 Feb 2023 at 12:37, Yunze Xu
> > wrote:
> >
> > > > I notice that the Java Client and the Java Admin Client are separate
> > > dependencies. Is this boundary important to maintain for other
> > > language admin clients?
> > >
> > > IMO, separating them is better to maintain. I had an idea to implement
> > > a pure C implementation of the Pulsar admin API. Only libcurl and
> > > openssl dependencies are required. Compared with the C++ library, the
> > > pure C library has smaller size, better ABI compatibility, and much
> > > quicker compilation speed than the C++ library, which has some more
> > > heavy dependencies like Boost and Protobuf.
> > >
> > > Thanks,
> > > Yunze
> > >
> > > On Fri, Feb 17, 2023 at 11:58 AM Michael Marshall
> > > wrote:
> > > >
> > > > I think it would be valuable to have admin clients in many languages.
> > > > Has anyone tried generating an admin client from our generated open
> > > > api spec?
> > > >
> > > > I notice that the Java Client and the Java Admin Client are separate
> > > > dependencies. Is this boundary important to maintain for other
> > > > language admin clients?
> > > >
> > > > Thanks,
> > > > Michael
> > > >
> > > > On Thu, Feb 16, 2023 at 7:47 PM ZhangJian He
> > wrote:
> > > > >
> > > > > I would like to express that the current Pulsar client for Go
> > > > > (pulsar-client-go) is missing the pulsar Admin API. As such, I would
> > > like
> > > > > to propose that we work towards adding this feature to
> > > pulsar-client-go.
> > > > >
> > > > > I believe that this new feature would be a valuable addition to
> > > > > pulsar-client-go, and I am excited to work to make it happen.
> > > > >
> > > > > I have submitted a PR:
> > > https://github.com/apache/pulsar-client-go/pull/959
> > > > > The full api is not currently available, but we are adding.
> > > > >
> > > > > Below is a simple example about how to use
> > > > >
> > > > > ## usage
> > > > >
> > > > > ```go
> > > > > package main
> > > > >
> > > > > import (
> > > > > "fmt"
> > > > > "github.com/apache/pulsar-client-go/padmin"
> > > > > )
> > > > >
> > > > > func main() {
> > > > > admin, err := padmin.NewDefaultPulsarAdmin()
> > > > > if err != nil {
> > > > > panic(err)
> > > > > }
> > > > > // get namespace topic list
> > > > > topics, err := admin.PersistentTopics.ListNamespaceTopics("tenant",
> > > > > "namespace")
> > > > > if err != nil {
> > > > > panic(err)
> > > > > }
> > > > > fmt.Println(topics)
> > > > > }
> > > > > ```
> > > > >
> > > > > Thanks
> > > > > ZhangJian He
> > >
> >
