I have reviewed the doc and it looks like a good feature!

+1

On Thu, Feb 6, 2020 at 11:47 AM Wellington Chevreuil <
[email protected]> wrote:

> 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 <
> [email protected]> 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 <[email protected]>
> > 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 <
> > > [email protected]> 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 <
> > > >> [email protected]> 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 <[email protected]> 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 <
> > > [email protected]
> > > >>>
> > > >>> 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
> > > >>>>
> > > >>>
> > > >>
> > >
> >
>

Reply via email to