Anup, thanks for bringing this up to the attention of the community. Some answers inline below.
Enrico Il giorno ven 23 ott 2020 alle ore 18:28 Anup Ghatage <ghat...@gmail.com> ha scritto: > Hi Bookies, > > I was going through the issues and the code and noticed there were a few > 'clean up' issues which have been there since some time and I was wondering > what's the community's opinion on them. > Often we have upstream consumers who use certain versions and depend on > certain APIs provided in those versions so it's best to socialize this > issue with everyone to know what's the best way forward. > > - *Moving the codahale and other loggers into their own packages.* > *Issue(s) link:* > https://github.com/apache/bookkeeper/issues/1262 > https://github.com/apache/bookkeeper/issues/762 > > * State: * > The files were moved into their own packages and the original classes > were marked as @Deprecated in 2018 commit -> > > https://github.com/apache/bookkeeper/commit/fc8097f33242d6b1a6cbcce10466fb5bfc663b5a > We have had a couple of releases after that (4.7.0 to 4.11.1) > > *Question to community:* > Shall we go ahead and remove the original Codahale*.java now that > they've been put in their own packages for multiple releases? > +1 for Removal > > - > *zkServers vs metadataServiceURI **Issue link:* > https://github.com/apache/bookkeeper/issues/1920 > > *State:* > We use config parameters zkServers and metadataServiceURI which both > serve the same purpose. We chose to deprecate zkServers and go with > metadataServiceURI. > zkServers was deprecated in 2018 commit -> > > https://github.com/apache/bookkeeper/commit/3d39435d316bc05e64c4247aeb8455bcd2a96989 > We have had a couple of releases after that (4.8.0 to 4.11.1) > AFAIK there are still many usages of this stuff around even in projects that moved to the new API and/or to the new metadata URI system. Probably it is still not time to remove this parameter. We should finish to make the new API able to substitute entirely the old one, then IMO it will be the right to to push for removing old stuff. Personally I am trying to keep a view on known OS projects that use BK, like Apache Pulsar, Pravega.io, HerdDB/Dienna stuff and try to help in upgrading to latest BK version. At Diennea we still need a few features, Nicolò with BP-42 il trying to reduce the gap, I will be also resuming the work about ExplicitLAC and the new API (it is not available yet) > > *Question to community:* > Is it a good time to remove all references of 'zkServers' and related > code now that we've had enough 'soak time'? > > - *CLIENT_TLS_KEYSTORE_TYPE -> TLS_KEYSTORE_TYPE* > *Issue link:* > No Issue created for this. > > *State:* > Since the 2018 commit -> > > https://github.com/apache/bookkeeper/commit/76c1fd0d8ad1358fc8799d66b6ec7f242fd2ba71 > We have reconfigured to use *TLS_KEYSTORE_TYPE* internally since 4.7.0 > release. > > *Question to community:* > Is it OK to retire CLIENT_TLS_* config values now? > +1 from my point of view, but I don't know users of this stuff. > > > > *Ending thoughts and my opinion:* > Cleaning up code is always difficult as it might break something for > someone using older versions. > My thought is to start cleaning up with the least impacting / used > @Deprecated code and move up. > For the high use functionalities which are mentioned above we all have to > agree on a path forward. > > Regards, > Anup > > -- > Anup Ghatage > www.ghatage.com >
