Re: [RESULT] [VOTE] Second release candidate for HBase 2.4.5 (RC1) is available

[clara xiong]

+1 (non-binding)

Passed chaos monkey test with 3 billion rows for 7 hours on a small cluster.

On Fri, Jul 30, 2021 at 4:09 PM Andrew Purtell 
wrote:

> With 5 binding +1 votes, including my own, and 2 non-binding +1 votes,
> and no 0 or -1 votes, this vote passes.
>
> Thanks to all who voted on the release candidate!
>
>
> On Tue, Jul 27, 2021 at 11:08 AM Andrew Purtell
>  wrote:
> >
> > Please vote on this Apache hbase release candidate,
> > hbase-2.4.5RC1
> >
> > The VOTE will remain open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache hbase 2.4.5
> > [ ] -1 Do not release this package because ...
> >
> > The tag to be voted on is 2.4.5RC1:
> >
> >   https://github.com/apache/hbase/tree/2.4.5RC1
> >
> > This tag currently points to git reference 03b8c0cf42.
> >
> > The release files, including signatures, digests, as well as CHANGES.md
> > and RELEASENOTES.md included in this RC can be found at:
> >
> >   https://dist.apache.org/repos/dist/dev/hbase/2.4.5RC1/
> >
> > The compatibility report for this RC can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/hbase/2.4.5RC1/api_compare_2.4.4_to_2.4.5RC1.html
> >
> > There are 0 reported compatibility issues.
> >
> > Maven artifacts are available in a staging repository at:
> >
> >
> https://repository.apache.org/content/repositories/orgapachehbase-1462/
> >
> > Artifacts were signed with the 0xD5365CCD key which can be found in:
> >
> >   https://dist.apache.org/repos/dist/release/hbase/KEYS
> >
> > To learn more about Apache hbase, please see
> >
> >   http://hbase.apache.org/
> >
> > Thanks,
> > Your HBase Release Manager
>
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

[jira] [Resolved] (HBASE-25544) Release 2.2.7

[Peter Somogyi (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-25544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Somogyi resolved HBASE-25544.
---
Resolution: Done

Resolving. 2.2.7 was released on Apr 16, 2021.

> Release 2.2.7
> -
>
> Key: HBASE-25544
> URL: https://issues.apache.org/jira/browse/HBASE-25544
> Project: HBase
>  Issue Type: Umbrella
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Major
>
> As discussed in [https://s.apache.org/7rqow] , the stable pointer had been 
> moved to 2.3.x and the final release for 2.2.x will be 2.2.7.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-26167) Allow users to not start zookeeper and dfs cluster when using TestingHBaseCluster

[Duo Zhang (Jira)]

Duo Zhang created HBASE-26167:
-

 Summary: Allow users to not start zookeeper and dfs cluster when 
using TestingHBaseCluster
 Key: HBASE-26167
 URL: https://issues.apache.org/jira/browse/HBASE-26167
 Project: HBase
  Issue Type: Sub-task
Reporter: Duo Zhang


Users may start zookeeper and dfs cluster outside TestingHBaseCluster to make 
different components share the same zookeeper and dfs cluster. We should allow 
users to not start zookeeper and dfs cluster when using TestingHBaseCluster, 
and maybe we could provide utility class to let users easily set the 
configurations to switch to external zookeeper and dfs cluster.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Contribution of a thrift2 python api

[Reid Chan]

Brief summaries from this thread:

I think you can push to hbase-connectors
 repo. Just create a new dir
hbase-thrift-python, and put your codes under it.
Your codes need to be reviewed by good Pythoners in the community.

Some follow-up tasks include (but not limited to):

   - requirements.txt
   - docs about how to release
   - some client examples
   - add some test codes (I'm not sure this part, whether there are similar
   conventions in python world)
   - other related information


About the *.thrfit files you mentioned, I can't come up a good idea by now.
Looks like we still need to create two separate PRs to update both hbase
and hbase-connectors repo.
However, as *.thrfit files seldom get updated, I feel it should be a ok.


--
Best Regards,
R.C


On Tue, Aug 3, 2021 at 10:42 AM Yutong Xiao  wrote:

> Hello, any other thoughts about this?
>
> Yutong Xiao  于2021年7月21日周三 上午11:30写道：
>
> > Hi. I have removed the personal info in the licenses. For the point 3.2,
> > thbase is dependent on the hbase.thrift file. I have involved the
> > hbase.thrift file, that thbase used, in the repo. In this case,  repo
> > separation will lead to a sync problem between the hbase.thrfit files in
> > HBase repo and the connector repo. I am concerned this may make it hard
> for
> > maintenance. What do you think?
> >
> > 张铎(Duo Zhang)  于2021年7月17日周六 上午9:39写道：
> >
> >> One of the difficulties of moving hbase-thrift and hbase-rest out is
> >> because we make use of hbase-http in these two modules, at least for
> >> setting up the status servlet...
> >>
> >> Sean Busbey  于2021年7月16日周五 下午11:01写道：
> >>
> >> > maybe a good fit for the hbase-connectors repo? I know we've talked a
> >> > few times about moving the thrift server out there. if we did both
> >> > then the compatibility question becomes just the standard
> >> > client/server compatibility provided the thrift server only uses our
> >> > public java client API.
> >> >
> >> > On Thu, Jul 15, 2021 at 10:21 PM Yutong Xiao 
> >> wrote:
> >> > >
> >> > > btw for point 2, if allowed I can do that.
> >> > > And for point 3.2 it is only a personal idea, the final decision
> >> should
> >> > be
> >> > > made by the community.
> >> > > Besides, many of my python user colleagues started using this
> library.
> >> > > I think many python users have the demand of a good HBase python
> >> client.
> >> > >
> >> > > Yutong Xiao  于2021年7月16日周五 上午11:07写道：
> >> > >
> >> > > > 1. The license is no problem.
> >> > > > 2. This should see if any committer or PMC has interests to do
> that.
> >> > > > 3. I can be responsible for those documents. About 3.2, as thbase
> >> has
> >> > been
> >> > > > uploaded to Pypi, I think it would be better if it is a new,
> >> separate
> >> > repo.
> >> > > >
> >> > > > Wei-Chiu Chuang  于2021年7月6日周二 上午10:22写道：
> >> > > >
> >> > > >> Hi
> >> > > >> thanks for your interest in contributing the python api to the
> >> HBase
> >> > > >> project.
> >> > > >>
> >> > > >> I quickly check and it doesn't look like there's another active
> >> python
> >> > > >> HBase thrift client project at this point.
> >> > > >> I don't have a demand to use a python thrift hbase client
> library.
> >> If
> >> > > >> there
> >> > > >> are people who will benefit from this library, then it's a good
> >> idea
> >> > to
> >> > > >> make sure the library is well maintained, by having it become
> part
> >> of
> >> > the
> >> > > >> Apache HBase project and that more developers can contribute to
> it.
> >> > > >>
> >> > > >> As a hobbyist Python developer I can help review/commit the
> patch.
> >> > > >>
> >> > > >> My two cents:
> >> > > >> (1) license: the code is ASL 2.0 so it's compatible. The text
> >> > "Copyright
> >> > > >> 2021 Yutong Sean" would need to be removed.
> >> > > >> (2) Apache Infra does not manage PyPi. So we (the Apache HBase
> >> project
> >> > > >> committers/PMC) will have to do that.
> >> > > >> I suspect we will have to replicate this PyPi project and add the
> >> > > >> interested HBase PMCs who's willing to do the release work.
> >> > > >> (3) compatibility matrix: we need to document what versions of
> >> HBase
> >> > > >> server
> >> > > >> is supported.
> >> > > >> (3) code:
> >> > > >> (3.1) You will need a requirements.txt and preferably specify the
> >> > versions
> >> > > >> of the dependencies.
> >> > > >> (3.2) If the community accepts it, should it be part of the HBase
> >> main
> >> > > >> repo, or a new, separate repo?
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> On Mon, Jul 5, 2021 at 7:12 PM Yutong Xiao  >
> >> > wrote:
> >> > > >>
> >> > > >> > Hi,
> >> > > >> >
> >> > > >> > I used to have a demand to deploy hbase thrift2 service for
> >> python
> >> > > >> users.
> >> > > >> > So that I developed a python clients API supporting python 2.7
> >> and
> >> > 3.x
> >> > > >> for
> >> > > >> > hbase thrift2, named thbase 
> .
> >> > > >> Besides
> >> > > >> > th

[jira] [Resolved] (HBASE-26126) Backport HBASE-25424 "Find a way to config OpenTelemetry tracing without directly depending on opentelemetry-sdk" to branch-2

[Tak-Lon (Stephen) Wu (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-26126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tak-Lon (Stephen) Wu resolved HBASE-26126.
--
Fix Version/s: 2.5.0
 Hadoop Flags: Reviewed
 Release Note: 
https://github.com/apache/hbase/commit/3d29c0c2b4520edb06c0c5d3674cdb6547a57651
   Resolution: Fixed

https://github.com/apache/hbase/commit/3d29c0c2b4520edb06c0c5d3674cdb6547a57651 
pushed to feature branch HBASE-25853

> Backport HBASE-25424 "Find a way to config OpenTelemetry tracing without 
> directly depending on opentelemetry-sdk" to branch-2
> -
>
> Key: HBASE-26126
> URL: https://issues.apache.org/jira/browse/HBASE-26126
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Tak-Lon (Stephen) Wu
>Assignee: Tak-Lon (Stephen) Wu
>Priority: Major
> Fix For: 2.5.0
>
>
> [3/17 commits of 
> HBASE-22120|https://github.com/apache/hbase/pull/2901/commits], original 
> commit of HBASE-25424 was 
> [https://github.com/apache/hbase/commit/57960fa8fa7228d65b1a4adc8e9b5b1a8158824d]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Split Meta Design Reset Status

[Stack]

Any time Yu Li!

No meeting tomorrow... Lets meet next week, the 10th.

Thanks,
S

On Wed, Jul 28, 2021 at 11:25 PM Yu Li  wrote:

> Thanks for the notes and efforts Stack, it's pretty helpful to know the
> progress and latest status of the work!
>
> Best Regards,
> Yu
>
>
> On Wed, 28 Jul 2021 at 12:13, Stack  wrote:
>
> > Note, no meeting tomorrow. We'll meet next week on the 4th or 5th of
> > August.
> > Thanks,
> > S
> >
> > On Thu, Jul 22, 2021 at 8:53 PM Stack  wrote:
> >
> > > Notes from yesterday's meeting (attendees, please amend if I
> misrepresent
> > > or if you have anything extra to add!)
> > >
> > > Split Meta Design Reset Status
> > >
> > > Wed Jul 21 21:24:38 PDT 2021
> > >
> > > Attendees: Bharath, Stack, Duo, and Francis
> > >
> > > We went over the new updates to the Brainstorming [1] section under
> > >
> > > Design in the Super Split Meta Design doc [2].
> > >
> > > First was the new addition, 4.1.2 Extend (& Move) ConnectionRegistry;
> > hide
> > >
> > > ROOT from Client [3]. In particular, filling out how "ROOT" might be
> > >
> > > implemented behind the new API in ConnectionRegistry. On option 1.,
> > >
> > > replicating master-local Region to RegionServers, options considered
> > >
> > > included
> > >
> > >  * Listener on master-local Region WAL to replicate.
> > >
> > >  * Perhaps Read-Replica but master-local is not an actual Region
> > >
> > >  * Needs to be incremental edits because ROOT could get too big to ship
> > >
> > >in a lump; need to visit how...
> > >
> > >  * Possibly in-memory-only Regions on RS replicated from master-local
> > >
> > >Region via WAL tailing <= zhang...@apache.org
> > >
> > >  * Which RegionServers? Those hosting ROOT replicas?
> > >
> > >  * How to bootstrap? Failure scenarios.
> > >
> > >  * This would be a new replication system alongside current; could
> > >
> > >evolve to replace/improve old?
> > >
> > > Duo offered to look into means of replicating the master-local Region
> > >
> > > out to RegionServers.
> > >
> > > Next up was discussion constrasting ROOT as a standalone table vs
> > >
> > > First-meta Region-as-Root (see 4.1.1 hbase:meta,,1 as ROOT [4]); i.e.
> > >
> > > options 2 and 3 for how we'd implement a ROOT. One item that came up
> > >
> > > was whether a need to specify one replica count for a ROOT table vs
> > >
> > > another for hbase:meta. If so, then it would be argument for ROOT as
> > >
> > > standalone table (Others of us argued it not a concern of consequence).
> > >
> > > If ROOT access is behind a new simple API in ConnectionRegistry, how
> > >
> > > to stop clients reading hbase:meta table if not Master or fronted by
> > >
> > > a ConnectionRegistry request? (Should be able to switch on client
> > >
> > > identity/source). One suggestion for First-meta-Region-as-ROOT was
> > >
> > > NOT returning the first Region to the client post-meta split when
> > >
> > > accessing via the simple API. Some concern this would confuse old
> > >
> > > Clients (Francis was going to take a look).
> > >
> > > Moved to discussion how we'd move ConnectionRegistry from
> > >
> > > hosted-by-Master to hosted-by-RegionServers. How to bootstrap such a
> > >
> > > system came up? Where do clients go? How do they know which
> > >
> > > RegionServers (special regionserver group?  Every RS fields
> > >
> > > ConnectionRegistry requests but only designated core serve the ROOT
> > >
> > > lookup APIs?). This was a TODO.
> > >
> > > This led naturally into 4.1.5 System RS group for client meta services
> > >
> > > [5], a new addition under Brainstorming. Discussion. Bharath to look
> > >
> > > into feedback.
> > >
> > > On the end of the discussion, group expressed support for adding
> > >
> > > simple API to the ConnectionRegistry to hide ROOT implementation
> > >
> > > detail from client. Support was expressed for moving ConnectionRegistry
> > >
> > > from Master to RegionServers. Intent is to move forward on design of
> > >
> > > these pieces: e.g. how client bootstraps.
> > >
> > > Support was expressed for getting at least the bones of a split meta
> > >
> > > into an hbase3 before the RCs.
> > >
> > > Where we'd actually store hbase:meta Region locations -- i.e. how a
> > >
> > > "ROOT' would be implemented -- was for our next meeting informed by
> > >
> > > research of the various approaches noted mostly above. It was
> > >
> > > also thought that the new ConnectionRegistry should not preclude
> > >
> > > making progress on the "ROOT" implementation.
> > >
> > > Will post notice of next meeting (next Weds or the one
> > >
> > > following).
> > >
> > > 1.
> > >
> >
> https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit#heading=h.wr0fwvw06j7n
> > >
> > > 2.
> > >
> >
> https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit#heading=h.9s666p6no9cq
> > >
> > > 3.
> > >
> >
> https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit#heading=h.90th11