Thanks for clarifying on this, Bharath and Andrew. Sorry for the late reply, +1 for adding it into branch-2 as well as non-default registry.
Em qui., 6 de fev. de 2020 às 00:59, Bharath Vissapragada < bhara...@apache.org> escreveu: > Whatever Andrew said. Wellington, I also addressed your comments in the > doc. Thanks for taking your time and going through it. Appreciate it. > > On Wed, Feb 5, 2020 at 2:29 PM Andrew Purtell <andrew.purt...@gmail.com> > wrote: > > > Which registry to use is a client side configuration so old clients are > > unaffected. (At some future time an operator might want to foreclose on > > direct ZK access with network or host ACLs but of course this is totally > up > > to them and they are in complete control.) > > > > > On Feb 5, 2020, at 2:12 PM, Wellington Chevreuil < > > wellington.chevre...@gmail.com> wrote: > > > > > > Thanks for the detailed summary, Bharath. I'm +1 for master. > > > > > > Just additional question I have, it wasn't clear for me on the > > doc/summary: > > > does it consider fallback to ZK based registry, in case of clients > > running > > > old versions on clusters with this feature enabled? > > > > > >> Em qua., 5 de fev. de 2020 às 07:37, Bharath Vissapragada < > > >> bhara...@apache.org> escreveu: > > >> > > >> Thanks everyone for chiming in. Sean, regarding your comments. > > >> > > >>> I don't see the current design doc in the feature branch > > >> (i.e.dev-support/design-docs) please include it there > > >> > > >> Of course, HBASE-23331 < > > https://issues.apache.org/jira/browse/HBASE-23331> > > >> is > > >> the subtask for this. The plan is to update the ref guide with all the > > >> details once the branch is merged in the master. I'll make sure to add > > the > > >> design doc too. > > >> > > >>> the current design doc has comments open still, should I assume those > > >> things haven't been addressed in the branch? or should I assume they > > have > > >> but it hasn't been updated yet? > > >> > > >> I addressed most of them already, forgot to resolve the comments. > There > > >> were some new comments since this email, so I addressed them and > > cleaned up > > >> the doc. Thanks for pointing it out. > > >> > > >>> On Tue, Feb 4, 2020 at 10:15 PM Stack <st...@duboce.net> wrote: > > >>> > > >>> I'm +1 for merge to master with it default enabled and to branch-2 > with > > >> it > > >>> off by default. > > >>> > > >>> Nice work Bharath. > > >>> > > >>> S > > >>> > > >>> On Tue, Feb 4, 2020 at 8:37 AM Bharath Vissapragada < > > bhara...@apache.org > > >>> > > >>> wrote: > > >>> > > >>>> Hello everyone, > > >>>> > > >>>> I'd like to kickoff a discuss thread on dev@ to see what folks > think > > >>> about > > >>>> merging the feature branch for HBASE-18095 > > >>>> <https://issues.apache.org/jira/browse/HBASE-18095> into the > master. > > >> For > > >>>> those of you who aren't following this work, over the last few > months, > > >> a > > >>>> lot of effort went into a feature branch > > >>>> < > > >>>> > > >>> > > >> > > > https://github.com/apache/hbase/tree/HBASE-18095/client-locate-meta-no-zookeeper > > >>>>> > > >>>> to > > >>>> remove the ZK dependency in the client. > > >>>> > > >>>> *Please refer to the design doc > > >>>> < > > >>>> > > >>> > > >> > > > https://docs.google.com/document/d/1JAJdM7eUxg5b417f0xWS4NztKCx1f2b6wZrudPtiXF4/edit > > >>>>> > > >>>> attached to the parent jira and go through the subtasks for all the > > >>>> technical details and design considerations*. > > >>>> > > >>>> *TL;DR*: With this feature, the client connection implementation > *does > > >>> not* > > >>>> need access to zookeeper to fetch the connection metadata. Instead, > a > > >>>> predefined set of master end points in the configuration are used by > > >>>> clients to fetch the required metadata. > > >>>> > > >>>> This new feature is *enabled by default on the feature branch* and > > >> passes > > >>>> the entire nightly test suite (modulo some known flakes not specific > > to > > >>> the > > >>>> branch). At this point, I'm not aware of any performance concerns / > > >>> feature > > >>>> gaps compared to original default implementation. The original > > registry > > >>>> implementation is still retained and can be used by setting the > > >> following > > >>>> client configuration. This kill switch gives the users more > > flexibility > > >>>> since they have a fallback incase they run into any issues. > > >>>> > > >>>> <property> > > >>>> <!-- Reverts to the original ZK based connection registry > > >>>> implementation --> > > >>>> <name>hbase.client.registry.impl</name> > > >>>> > <value>org.apache.hadoop.hbase.client.ZKConnectionRegistry</value> > > >>>> </property> > > >>>> > > >>>> This work is also slated to go into the upcoming releases* 2.3.0* > and > > >>>> *1.6.0*. However, it will be *disabled by default*. Having this work > > >> back > > >>>> ported to those branches enables users to try it out in their > > >>> environments > > >>>> and report any feedback. > > >>>> > > >>>> Please speak up (respond to this email) if there are any objections > to > > >>>> merging this work in the master branch. > > >>>> > > >>>> Many thanks to Nick Dimiduk, Andrew Purtell and Michael Stack for > > their > > >>>> invaluable feedback throughout this work. > > >>>> > > >>>> - Bharath > > >>>> > > >>> > > >> > > >
