Hi Paolo, Replies in line...
On 28 July 2017 at 11:14, Paolo Patierno <ppatie...@live.com> wrote: > Hi committers, > > in my understanding there is the common idea to move all tools from Scala > to Java and then using the new Admin Client API instead of using the > Zookeeper connection. > > Regarding this subject I started to work on refactoring the TopicCommand > tool but with two steps at same time : > > > * re-writing it in Java > * removing --zookeeper option (so no Zookeeper connection) and adding > --broker-list option (so using the Admin Client API) > > Of course, such option substitution is a breaking change for the tool (and > the users who are using it). > In such a scenario, the two steps path should be needed : first > deprecation, then removal (for the --zookeeper option) > A change to tools (and their options) requires a KIP. There's no fundamental reason why both couldn't be supported during a transition period. So I doubt a KIP that didn't propose a transition period would get passed. It seems that in the "deprecation" phase we have two possible solutions : > > > 1. Adding Admin Client API to the Scala tools and so the --broker-list > option and a warning on --zookeeper for deprecation > 2. Rewriting the tool in Java using the Admin Client API (so > --broker-list) but at same time providing --zookeeper as well (so Zookeeper > connection) > > With the solution 2) we have the advantage to have the tool already in > Java when the --zookeeper option will be removed in a next step. In any > case we have to write the part related to use the Admin Client API so it > make more sense to me option 2) porting the Zookeeper needed code from > Scala to Java (then removing it in the next phase). > > Is my understanding right on how we have to handle deprecation and removal > for something that is a breaking change ? > Or this case is something "special" and we can live with a new Java based > tool without zookeeper but with Admin Client API at same time ? > > Of course having both Admin Client API and Zookeeper utils working at the > same time in the tools means more complexity in the code but it's something > that could be factorized. > I think the right thing to do would be: 1. deprecate the old option, adding support for the replacement option (using the AdminClient). Keep the code in scala. All this is in one KIP. 2. Remove the old option (needs a KIP) 3. Rewrite the tool in Java. Parts 2 and 3 could be done at the same time. I don't believe part 3 needs a KIP if it were a drop-in replacement. The reason I think this is the right way to proceed is: * It gives users a transition period to learn about the new option, and replace any tooling of their own. * By keeping the tool in scala you get to release your new AdminClient API and get to iron out all the creases while users still have the --zookeeper option as a fallback. * Then when you know the AdminClient API works in the field you have a straight porting job to do, and you have less code to port because you don't have to port the code to support --zookeeper. But I'm fairly new here, so maybe a committer will chime in an correct me where I'm wrong! Cheers, Tom
