Hi Paolo, Another option is to write the new tool in Java without support for `--zookeeper` and include some logic in the shell script to pick the implementation based on the presence of `--bootstrap-server` or `--zookeeper`. This would mean that we can deprecate the Scala tool while still supporting it for existing users.
I think this would involve the least amount of rewriting once we drop support for `--zookeeper`. Thoughts? Ismael On Tue, Aug 1, 2017 at 3:30 PM, Paolo Patierno <ppatie...@live.com> wrote: > Hi Tom, > > > thanks for your reply. I think that you are right and what you have > proposed should be the way to go. > > > Until today I have been working on refactoring the TopicCommand tool in > Java using the AdminClient getting rid of the Zookeeper usage in only "one > step" and maybe it's wrong. > > I'd like to have some input from committers as well to be sure that the > way is good about how handling such use cases. > > > Thanks, > > > Paolo Patierno > Senior Software Engineer (IoT) @ Red Hat > Microsoft MVP on Windows Embedded & IoT > Microsoft Azure Advisor > > Twitter : @ppatierno<http://twitter.com/ppatierno> > Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno> > Blog : DevExperience<http://paolopatierno.wordpress.com/> > > > ________________________________ > From: Tom Bentley <t.j.bent...@gmail.com> > Sent: Friday, July 28, 2017 10:36 AM > To: dev@kafka.apache.org > Subject: Re: Command tools : from Scala to Java, from Zookeeper utils to > Admin Client API > > 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 >
