Hi all,
I wanted to let you know that I have made the following small change to the
`kafka-features` CLI tool description in the KIP-584 write up. The purpose
is to ensure the design is compatible with post KIP-500 world. I have
eliminated the facility in Admin#describeFeatures API to be able to
o
Hi, Kowshik,
Thanks for the update. Those changes look good to me.
Jun
On Tue, Oct 13, 2020 at 4:50 PM Kowshik Prakasam
wrote:
> Hi all,
>
> I wanted to let you know that I have made the following minor changes to
> the `kafka-features` CLI tool description in the KIP-584 write up. The
> purpo
Hi all,
I wanted to let you know that I have made the following minor changes to
the `kafka-features` CLI tool description in the KIP-584 write up. The
purpose is to ensure the design is correct for a few things which came up
during implementation:
1. The CLI tool now produces a tab-formatted out
Hi Jun,
This is a very good point. I have updated the feature version deprecation
section mentioning the same:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-584%3A+Versioning+scheme+for+features#KIP584:Versioningschemeforfeatures-Featureversiondeprecation
.
Thank you for the suggestion.
Hi, Kowshik,
Thanks for the follow up. Both look good to me.
For 2, it would be useful to also add that an admin should make sure that
no clients are using a deprecated feature version (e.g. using the client
version metric) before deploying a release that deprecates it.
Thanks,
Jun
On Tue, Oct
Hi Jun,
I have added the following details in the KIP-584 write up:
1. Deployment, IBP deprecation and avoidance of double rolls. This section
talks about the various phases of work that would be required to use this
KIP to eventually avoid Broker double rolls in the cluster (whenever IBP
values
Hi, Kowshik,
Thanks for the update. Regarding enabling a single rolling restart in the
future, could we sketch out a bit how this will work by treating IBP as a
feature? For example, IBP currently uses the release version and this KIP
uses an integer for versions. How do we bridge the gap between
Hi Colin,
Thanks for the feedback. Those are very good points. I have made the
following changes to the KIP as you had suggested:
1. Included the `timeoutMs` field in the `UpdateFeaturesRequest` schema.
The initial implementation won't be making use of the field, but we can
always use it in the fu
Hi Jun,
Thanks for the feedback. It's a very good point. I have now modified the
KIP-584 write-up "goals" section a bit. It now mentions one of the goals as
enabling rolling upgrades using a single restart (instead of 2). Also I
have removed the text explicitly aiming for deprecation of IBP. Note
On Tue, Sep 22, 2020, at 00:43, Kowshik Prakasam wrote:
> Hi all,
>
> I wanted to let you know that I have made the following changes to the
> KIP-584 write up. The purpose is to ensure the design is correct for a few
> things which came up during implementation:
>
Hi Kowshik,
Thanks for the upd
Hi, Kowshik,
Thanks for the update. Those changes seem fine to me.
One of the goals listed in this KIP is the removal of IBP in the future.
Recent discussion in KIP-590 intends to expand the scope of IBP for
forwarding requests to the controller. In light of this, is the goal of
removing IBP stil
Hi all,
I wanted to let you know that I have made the following changes to the
KIP-584 write up. The purpose is to ensure the design is correct for a few
things which came up during implementation:
1. Per FeatureUpdate error code: The UPDATE_FEATURES controller API is no
longer transactional. Goi
Hi all,
I wanted to let you know that I have made the following minor changes to
the KIP-584 write up. The purpose is to ensure the design is correct for a
few things which came up during implementation:
1. Feature version data type has been made to be int16 (instead of int64).
The reason is two
Hi all,
This KIP vote has been open for ~12 days. The summary of the votes is that
we have 3 binding votes (Colin, Guozhang, Jun), and 3 non-binding votes
(David, Dhruvil, Boyang). Therefore, the KIP vote passes. I'll mark KIP as
accepted and start working on the implementation.
Thanks a lot!
C
Thanks, Kowshik. +1 (binding)
best,
Colin
On Sat, Apr 25, 2020, at 13:20, Kowshik Prakasam wrote:
> Hi Colin,
>
> Thanks for the explanation! I agree with you, and I have updated the
> KIP.
> Here is a link to relevant section:
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-584%3A+Ver
Hi Colin,
Thanks for the explanation! I agree with you, and I have updated the KIP.
Here is a link to relevant section:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-584%3A+Versioning+scheme+for+features#KIP-584:Versioningschemeforfeatures-Controller:ZKnodebootstrapwithdefaultvalues
Chee
On Fri, Apr 24, 2020, at 00:01, Kowshik Prakasam wrote:
> (Kowshik): Great point! However for case #1, I'm not sure why we need to
> create a '/features' ZK node with disabled features. Instead, do you see
> any drawback if we just do not create it? i.e. if IBP is less than 2.6, the
> controller tr
Hi Colin,
Thanks a lot for the excellent feedback and great
ideas/questions/suggestions. I have updated the KIP based on the feedback.
Please find my response below to the comments.
> It would be good to note that deprecating a feature version (in other
words, increasing minVersionLevel on the br
Hi Kowshik,
Thanks again for working on this-- it looks great. I went over the KIP again
and have a few more comments.
===
It would be good to note that deprecating a feature version (in other words,
increasing minVersionLevel on the broker) is an incompatible change, which
requires a major
Thanks for the KIP! +1 (non-binding)
On Tue, Apr 21, 2020 at 6:09 AM David Jacot wrote:
> Great KIP, thanks! +1 (non-binding)
>
> On Fri, Apr 17, 2020 at 8:56 PM Guozhang Wang wrote:
>
> > Thanks for the great KIP Kowshik, +1 (binding).
> >
> > On Fri, Apr 17, 2020 at 11:22 AM Jun Rao wrote:
>
Great KIP, thanks! +1 (non-binding)
On Fri, Apr 17, 2020 at 8:56 PM Guozhang Wang wrote:
> Thanks for the great KIP Kowshik, +1 (binding).
>
> On Fri, Apr 17, 2020 at 11:22 AM Jun Rao wrote:
>
> > Hi, Kowshik,
> >
> > Thanks for the KIP. +1
> >
> > Jun
> >
> > On Thu, Apr 16, 2020 at 11:14 AM K
Thanks for the great KIP Kowshik, +1 (binding).
On Fri, Apr 17, 2020 at 11:22 AM Jun Rao wrote:
> Hi, Kowshik,
>
> Thanks for the KIP. +1
>
> Jun
>
> On Thu, Apr 16, 2020 at 11:14 AM Kowshik Prakasam
> wrote:
>
> > Hi all,
> >
> > I'd like to start a vote for KIP-584. The link to the KIP can be
Hi, Kowshik,
Thanks for the KIP. +1
Jun
On Thu, Apr 16, 2020 at 11:14 AM Kowshik Prakasam
wrote:
> Hi all,
>
> I'd like to start a vote for KIP-584. The link to the KIP can be found
> here:
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-584%3A+Versioning+scheme+for+features
> .
>
>
Thanks Kowshik for driving this effort, I'm +1 (non-binding).
On Thu, Apr 16, 2020 at 11:14 AM Kowshik Prakasam
wrote:
> Hi all,
>
> I'd like to start a vote for KIP-584. The link to the KIP can be found
> here:
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-584%3A+Versioning+scheme+f
Hi all,
I'd like to start a vote for KIP-584. The link to the KIP can be found here:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-584%3A+Versioning+scheme+for+features
.
Thanks!
Cheers,
Kowshik
25 matches
Mail list logo
