Re: hbase does not seem to handle mixed workloads well

[杨苏立 Yang Su Li]

On Fri, Mar 31, 2017 at 9:39 PM, Ted Yu  wrote:

> Can you tell us which release of hbase you used ?
>

2.0.0 Snapshot

>
> Please describe values for the config parameters in hbase-site.xml
>
> The content of hbase-site.xml is shown below, but indeed this problem is
not sensitive to configuration -- we can reproduce the same problem with
different configurations, and across different hbase version.


> Do you have SSD(s) in your cluster ?
> If so and the mixed workload involves writes, have you taken a look at
> HBASE-12848
> ?
>
No, we don't use SSD (for hbase). And the workload does not involve writes
(even though workload with writes show similar behavior). I stated that
both clients are doing 1KB Gets.




hbase-master
node0.orighbasecluster.distsched-pg0.wisc.cloudlab.us:6



hbase.rootdir
hdfs://
node0.orighbasecluster.distsched-pg0.wisc.cloudlab.us:9000/hbase



hbase.fs.tmp.dir
hdfs://
node0.orighbasecluster.distsched-pg0.wisc.cloudlab.us:9000/hbase-staging




hbase.cluster.distributed
true



hbase.zookeeper.property.dataDir
/tmp/zookeeper



hbase.zookeeper.property.clientPort
2181



hbase.zookeeper.quorum
node0.orighbasecluster.distsched-pg0.wisc.cloudlab.us



hbase.ipc.server.read.threadpool.size
10



hbase.regionserver.handler.count
30






>
> Cheers
>
> On Fri, Mar 31, 2017 at 7:29 PM, 杨苏立 Yang Su Li 
> wrote:
>
> > Hi,
> >
> > We found that when there is a mix of CPU-intensive and I/O intensive
> > workload, HBase seems to slow everything down to the disk throughput
> level.
> >
> > This is shown in the performance graph at
> > http://pages.cs.wisc.edu/~suli/blocking-orig.pdf : both client-1 and
> > client-2 are issuing 1KB Gets. From second 0 , both repeatedly access a
> > small set of data that is cachable and both get high throughput (~45k
> > ops/s). At second 60, client-1 switch to an I/O intensive workload and
> > begins to randomly access a large set of data (does not fit in cache).
> > *Both* client-1 and client-2's throughput drops to ~0.5K ops/s.
> >
> > Is this acceptable behavior for HBase or is it considered a bug or
> > performance drawback?
> > I can find an old JIRA entry about similar problems (
> > https://issues.apache.org/jira/browse/HBASE-8836), but that was never
> > resolved.
> >
> > Thanks.
> >
> > Suli
> >
> > --
> > Suli Yang
> >
> > Department of Physics
> > University of Wisconsin Madison
> >
> > 4257 Chamberlin Hall
> > Madison WI 53703
> >
>



-- 
Suli Yang

Department of Physics
University of Wisconsin Madison

4257 Chamberlin Hall
Madison WI 53703

Re: Fwd: Successful: HBase Generate Website

[Nick Dimiduk]

Thanks Misty! You are a- automation-mazing!

On Fri, Mar 31, 2017 at 3:06 PM Misty Stanley-Jones 
wrote:

> And emails will now only go out if the job fails, so you won't see these
> anymore at all.
>
> On Fri, Mar 31, 2017, at 03:03 PM, Misty Stanley-Jones wrote:
> > FYI, the linked Jenkins job now automatically updates the site! No more
> > need to manually push. Merry Christmas! :)
> >
> > - Original message -
> > From: Apache Jenkins Server 
> > To: dev@hbase.apache.org
> > Subject: Successful: HBase Generate Website
> > Date: Fri, 31 Mar 2017 21:32:17 + (UTC)
> >
> > Build status: Successful
> >
> > If successful, the website and docs have been generated and the site has
> > been updated automatically.
> > If failed, see
> > https://builds.apache.org/job/hbase_generate_website/561/console
> >
> > YOU DO NOT NEED TO DO THE FOLLOWING ANYMORE! It is here for
> > informational purposes and shows what the Jenkins job does to push the
> > site.
> >
> >   git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git
> >   cd hbase-site
> >   wget -O-
> >
> https://builds.apache.org/job/hbase_generate_website/561/artifact/website.patch.zip
> >   | funzip > 1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7.patch
> >   git fetch
> >   git checkout -b asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7
> >   origin/asf-site
> >   git am --whitespace=fix 1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7.patch
> >   git push origin
> >   asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7:asf-site
> >   git commit --allow-empty -m "INFRA-10751 Empty commit"
> >   git push origin asf-site
> >   git checkout asf-site
> >   git branch -D asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7
> >
> >
> >
>

Re: hbase does not seem to handle mixed workloads well

[Ted Yu]

Can you tell us which release of hbase you used ?

Please describe values for the config parameters in hbase-site.xml

Do you have SSD(s) in your cluster ?
If so and the mixed workload involves writes, have you taken a look at
HBASE-12848
?

Cheers

On Fri, Mar 31, 2017 at 7:29 PM, 杨苏立 Yang Su Li  wrote:

> Hi,
>
> We found that when there is a mix of CPU-intensive and I/O intensive
> workload, HBase seems to slow everything down to the disk throughput level.
>
> This is shown in the performance graph at
> http://pages.cs.wisc.edu/~suli/blocking-orig.pdf : both client-1 and
> client-2 are issuing 1KB Gets. From second 0 , both repeatedly access a
> small set of data that is cachable and both get high throughput (~45k
> ops/s). At second 60, client-1 switch to an I/O intensive workload and
> begins to randomly access a large set of data (does not fit in cache).
> *Both* client-1 and client-2's throughput drops to ~0.5K ops/s.
>
> Is this acceptable behavior for HBase or is it considered a bug or
> performance drawback?
> I can find an old JIRA entry about similar problems (
> https://issues.apache.org/jira/browse/HBASE-8836), but that was never
> resolved.
>
> Thanks.
>
> Suli
>
> --
> Suli Yang
>
> Department of Physics
> University of Wisconsin Madison
>
> 4257 Chamberlin Hall
> Madison WI 53703
>

hbase does not seem to handle mixed workloads well

[杨苏立 Yang Su Li]

Hi,

We found that when there is a mix of CPU-intensive and I/O intensive
workload, HBase seems to slow everything down to the disk throughput level.

This is shown in the performance graph at
http://pages.cs.wisc.edu/~suli/blocking-orig.pdf : both client-1 and
client-2 are issuing 1KB Gets. From second 0 , both repeatedly access a
small set of data that is cachable and both get high throughput (~45k
ops/s). At second 60, client-1 switch to an I/O intensive workload and
begins to randomly access a large set of data (does not fit in cache).
*Both* client-1 and client-2's throughput drops to ~0.5K ops/s.

Is this acceptable behavior for HBase or is it considered a bug or
performance drawback?
I can find an old JIRA entry about similar problems (
https://issues.apache.org/jira/browse/HBASE-8836), but that was never
resolved.

Thanks.

Suli

-- 
Suli Yang

Department of Physics
University of Wisconsin Madison

4257 Chamberlin Hall
Madison WI 53703

Re: About the InterfaceStability annotation for public API

[Jerry He]

Looks fine.

Incorporating another public dimension probably makes the version scheme
too complex.   Keep it simple.

Jerry

On Fri, Mar 31, 2017 at 5:30 PM 张铎(Duo Zhang)  wrote:

> Some progress here.
>
> In HBASE-17857, a sub task of HBASE-17828, I've created a script to remove
> all the IS annotations for the IA.Public API. And I've also changed the
> IA.Public annotations for several classes which are marked as IS.Unstable
> to IA.Private. We can change them back when we think they are stable
> enough.
>
> The patch is ready to land. Will commit it today if no objections.
>
> Thanks.
>
> 2017-03-24 9:48 GMT+08:00 张铎(Duo Zhang) :
>
> > Filed https://issues.apache.org/jira/browse/HBASE-17828
> >
> > 2017-03-21 8:36 GMT+08:00 张铎(Duo Zhang) :
> >
> >> bq.  If someone is
> >> comfortable with the risk of an API that can change in minor or
> >> maintenance releases, what's gained by calling it IA.Public +
> >> IS.Evolving or Unstable rather than just labeling it IA.Private or
> >> IA.LimitedPrivate?
> >>
> >> Indeed. We can not stop users use IA.Private classes if they are
> declared
> >> as public class. The users take the risk by themselves.
> >>
> >> Anyway, seems we all agree that at least we need to update our
> >> documentation. So let me open a issue first. We can continue the
> discussion
> >> there.
> >>
> >> Thanks.
> >>
> >> 2017-03-21 4:27 GMT+08:00 Jerry He :
> >>
> >>> Just to bring up an alternative idea.
> >>> The Spark InterfaceStability explicitly spells out what can or can not
> >>> change from major or minor releases. (I was onto it recently).
> >>> See [1]
> >>>
> >>> HBase is probably a more stable project that does not have to do the
> >>> same.
> >>> But it is also possible that we may have new features (i.e.
> AsyncClient,
> >>> Backup, etc) that we want to evolve within a major release.
> >>> We should see if we want to provide such flexibility via the
> >>> InterfaceStability annotations and document it explicitly if yes.
> >>>
> >>> Thanks,
> >>>
> >>> Jerry
> >>>
> >>>
> >>> 1. https://github.com/apache/spark/blob/master/common/tags/
> >>> src/main/java/org/apache/spark/annotation/InterfaceStability.java
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Mar 20, 2017 at 10:46 AM, Yu Li  wrote:
> >>>
> >>> > +1 on removing InterfaceStability annotation for IA.Public. Even
> more,
> >>> is
> >>> > it possible to forbid using these two annotations together in Yetus
> at
> >>> > code-level if we are migrating to it (as mentioned in another
> thread)?
> >>> >
> >>> > For IA.Private or IA.LimitedPrivate, personally I think
> >>> InterfaceStability
> >>> > is still a useful annotation.
> >>> >
> >>> > Best Regards,
> >>> > Yu
> >>> >
> >>> > On 20 March 2017 at 22:07, Sean Busbey  wrote:
> >>> >
> >>> > > I really dislike having InterfaceStability markings on IA.Public
> >>> > > interfaces, because to me it reads like us essentially saying we
> >>> > > didn't invest enough time in deciding what something should look
> like
> >>> > > before declaring it safe for downstream folks. If someone is
> >>> > > comfortable with the risk of an API that can change in minor or
> >>> > > maintenance releases, what's gained by calling it IA.Public +
> >>> > > IS.Evolving or Unstable rather than just labeling it IA.Private or
> >>> > > IA.LimitedPrivate?
> >>> > >
> >>> > > So I'd be +1 on updating our docs to state that InterfaceStability
> is
> >>> > > just for IA.LimitedPrivate or even discontinuing our use of it
> >>> > > entirely.
> >>> > >
> >>> > > On Sun, Mar 19, 2017 at 11:28 PM, Duo Zhang 
> >>> wrote:
> >>> > > > In the compatibility section of our refguide, the compatibility
> for
> >>> > patch
> >>> > > > version, minor version and major version is not related
> >>> > > > to InterfaceStability annotation. The only place we mention it is
> >>> for
> >>> > > > Server-Side Limited API compatibility.
> >>> > > >
> >>> > > > And  in the Developer Guidelines section, we say this
> >>> > > > @InterfaceStability.Evolving
> >>> > > >
> >>> > > > Public packages marked as evolving may be changed, but it is
> >>> > discouraged.
> >>> > > > I think this is a little confusing, esepecially that the comment
> >>> > > > of InterfaceStability also mentions the compatibility for patch,
> >>> minor
> >>> > > and
> >>> > > > major release.
> >>> > > >
> >>> > > > For me, I think only InterfaceStability.Unstable is useful for
> >>> public
> >>> > > API.
> >>> > > > It means the API is still experimental and will not respect the
> >>> > > > compatibility rule.
> >>> > > >
> >>> > > > So here I suggest we just remove the InterfaceStability annoation
> >>> for
> >>> > the
> >>> > > > classes which are marked as InterfaceAudience.Public, and change
> >>> the
> >>> > > > comment of InterfaceStability and also the refguide to be more
> >>> > specific.
> >>> > > >
> >>> > > > 

Re: About the InterfaceStability annotation for public API

[Duo Zhang]

Some progress here.

In HBASE-17857, a sub task of HBASE-17828, I've created a script to remove
all the IS annotations for the IA.Public API. And I've also changed the
IA.Public annotations for several classes which are marked as IS.Unstable
to IA.Private. We can change them back when we think they are stable enough.

The patch is ready to land. Will commit it today if no objections.

Thanks.

2017-03-24 9:48 GMT+08:00 张铎(Duo Zhang) :

> Filed https://issues.apache.org/jira/browse/HBASE-17828
>
> 2017-03-21 8:36 GMT+08:00 张铎(Duo Zhang) :
>
>> bq.  If someone is
>> comfortable with the risk of an API that can change in minor or
>> maintenance releases, what's gained by calling it IA.Public +
>> IS.Evolving or Unstable rather than just labeling it IA.Private or
>> IA.LimitedPrivate?
>>
>> Indeed. We can not stop users use IA.Private classes if they are declared
>> as public class. The users take the risk by themselves.
>>
>> Anyway, seems we all agree that at least we need to update our
>> documentation. So let me open a issue first. We can continue the discussion
>> there.
>>
>> Thanks.
>>
>> 2017-03-21 4:27 GMT+08:00 Jerry He :
>>
>>> Just to bring up an alternative idea.
>>> The Spark InterfaceStability explicitly spells out what can or can not
>>> change from major or minor releases. (I was onto it recently).
>>> See [1]
>>>
>>> HBase is probably a more stable project that does not have to do the
>>> same.
>>> But it is also possible that we may have new features (i.e. AsyncClient,
>>> Backup, etc) that we want to evolve within a major release.
>>> We should see if we want to provide such flexibility via the
>>> InterfaceStability annotations and document it explicitly if yes.
>>>
>>> Thanks,
>>>
>>> Jerry
>>>
>>>
>>> 1. https://github.com/apache/spark/blob/master/common/tags/
>>> src/main/java/org/apache/spark/annotation/InterfaceStability.java
>>>
>>>
>>>
>>>
>>> On Mon, Mar 20, 2017 at 10:46 AM, Yu Li  wrote:
>>>
>>> > +1 on removing InterfaceStability annotation for IA.Public. Even more,
>>> is
>>> > it possible to forbid using these two annotations together in Yetus at
>>> > code-level if we are migrating to it (as mentioned in another thread)?
>>> >
>>> > For IA.Private or IA.LimitedPrivate, personally I think
>>> InterfaceStability
>>> > is still a useful annotation.
>>> >
>>> > Best Regards,
>>> > Yu
>>> >
>>> > On 20 March 2017 at 22:07, Sean Busbey  wrote:
>>> >
>>> > > I really dislike having InterfaceStability markings on IA.Public
>>> > > interfaces, because to me it reads like us essentially saying we
>>> > > didn't invest enough time in deciding what something should look like
>>> > > before declaring it safe for downstream folks. If someone is
>>> > > comfortable with the risk of an API that can change in minor or
>>> > > maintenance releases, what's gained by calling it IA.Public +
>>> > > IS.Evolving or Unstable rather than just labeling it IA.Private or
>>> > > IA.LimitedPrivate?
>>> > >
>>> > > So I'd be +1 on updating our docs to state that InterfaceStability is
>>> > > just for IA.LimitedPrivate or even discontinuing our use of it
>>> > > entirely.
>>> > >
>>> > > On Sun, Mar 19, 2017 at 11:28 PM, Duo Zhang 
>>> wrote:
>>> > > > In the compatibility section of our refguide, the compatibility for
>>> > patch
>>> > > > version, minor version and major version is not related
>>> > > > to InterfaceStability annotation. The only place we mention it is
>>> for
>>> > > > Server-Side Limited API compatibility.
>>> > > >
>>> > > > And  in the Developer Guidelines section, we say this
>>> > > > @InterfaceStability.Evolving
>>> > > >
>>> > > > Public packages marked as evolving may be changed, but it is
>>> > discouraged.
>>> > > > I think this is a little confusing, esepecially that the comment
>>> > > > of InterfaceStability also mentions the compatibility for patch,
>>> minor
>>> > > and
>>> > > > major release.
>>> > > >
>>> > > > For me, I think only InterfaceStability.Unstable is useful for
>>> public
>>> > > API.
>>> > > > It means the API is still experimental and will not respect the
>>> > > > compatibility rule.
>>> > > >
>>> > > > So here I suggest we just remove the InterfaceStability annoation
>>> for
>>> > the
>>> > > > classes which are marked as InterfaceAudience.Public, and change
>>> the
>>> > > > comment of InterfaceStability and also the refguide to be more
>>> > specific.
>>> > > >
>>> > > > Suggestions are welcomed.
>>> > > >
>>> > > > Thanks.
>>> > >
>>> >
>>>
>>
>>
>

Re: Remove invalid '2.0' and '2.0..' verions from jira

[Duo Zhang]

Yeah I've already done it when sending the first email :)
Josh Elser 于2017年4月1日 周六02:27写道：

> Just checked and I don't see 'em there anymore. I assume someone else
> has already done this :)
>
> Enis Söztutar wrote:
> > Thanks for the cleanup. Indeed we should remove these from jira admin so
> > that they don't show up in auto-fill.
> >
> > Enis
> >
> > On Fri, Mar 31, 2017 at 8:34 AM, Stack  wrote:
> >
> >> On Thu, Mar 30, 2017 at 7:02 PM, Duo Zhang  wrote:
> >>
> >>> There are plenty of issues which are assigned a version called '2.0' OR
> >>> '2.0..'.
> >>>
> >>> The latter one is a typo I think. And for the former one, I think we
> >> should
> >>> claim again that the first release for 2.x release line is 2.0.0, not
> >> 2.0.
> >>> So do not use 2.0 anymore. We committers should be careful when opening
> >>> issues or resolving issues.
> >>>
> >>> Thanks.
> >>>
> >> Thanks Duo. I could admin removing these mis-versions?
> >> St.Ack
> >>
> >
>

[jira] [Created] (HBASE-17863) Procedure V2: Some cleanup around isFinished() and procedure executor

[Umesh Agashe (JIRA)]

Umesh Agashe created HBASE-17863:


 Summary: Procedure V2: Some cleanup around isFinished() and 
procedure executor
 Key: HBASE-17863
 URL: https://issues.apache.org/jira/browse/HBASE-17863
 Project: HBase
  Issue Type: Bug
  Components: proc-v2
Reporter: Umesh Agashe
Assignee: Umesh Agashe


Clean up around isFinished() and procedure executor



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Updated Code of Conduct

[Misty Stanley-Jones]

All,

We have updated the Code of Conduct to be a little more explicit about
how much we value diversity in the HBase project, and to ask for your
feedback on how we can improve. Your feedback is ALWAYS welcome, whether
on one of the public mailing lists or privately to a committer or a PMC
member on the project. On behalf of the entire PMC, thank you for being
part of the HBase project, and for all of the amazing work you all do!

See the changes at http://hbase.apache.org/coc.html.

Thanks,
Misty

Re: Fwd: Successful: HBase Generate Website

[Misty Stanley-Jones]

And emails will now only go out if the job fails, so you won't see these
anymore at all.

On Fri, Mar 31, 2017, at 03:03 PM, Misty Stanley-Jones wrote:
> FYI, the linked Jenkins job now automatically updates the site! No more
> need to manually push. Merry Christmas! :)
> 
> - Original message -
> From: Apache Jenkins Server 
> To: dev@hbase.apache.org
> Subject: Successful: HBase Generate Website
> Date: Fri, 31 Mar 2017 21:32:17 + (UTC)
> 
> Build status: Successful
> 
> If successful, the website and docs have been generated and the site has
> been updated automatically.
> If failed, see
> https://builds.apache.org/job/hbase_generate_website/561/console
> 
> YOU DO NOT NEED TO DO THE FOLLOWING ANYMORE! It is here for
> informational purposes and shows what the Jenkins job does to push the
> site.
> 
>   git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git
>   cd hbase-site
>   wget -O-
>   
> https://builds.apache.org/job/hbase_generate_website/561/artifact/website.patch.zip
>   | funzip > 1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7.patch
>   git fetch
>   git checkout -b asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7
>   origin/asf-site
>   git am --whitespace=fix 1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7.patch
>   git push origin
>   asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7:asf-site
>   git commit --allow-empty -m "INFRA-10751 Empty commit"
>   git push origin asf-site
>   git checkout asf-site
>   git branch -D asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7
> 
> 
> 

Fwd: Successful: HBase Generate Website

[Misty Stanley-Jones]

FYI, the linked Jenkins job now automatically updates the site! No more
need to manually push. Merry Christmas! :)

- Original message -
From: Apache Jenkins Server 
To: dev@hbase.apache.org
Subject: Successful: HBase Generate Website
Date: Fri, 31 Mar 2017 21:32:17 + (UTC)

Build status: Successful

If successful, the website and docs have been generated and the site has
been updated automatically.
If failed, see
https://builds.apache.org/job/hbase_generate_website/561/console

YOU DO NOT NEED TO DO THE FOLLOWING ANYMORE! It is here for
informational purposes and shows what the Jenkins job does to push the
site.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git
  cd hbase-site
  wget -O-
  
https://builds.apache.org/job/hbase_generate_website/561/artifact/website.patch.zip
  | funzip > 1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7.patch
  git fetch
  git checkout -b asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7
  origin/asf-site
  git am --whitespace=fix 1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7.patch
  git push origin
  asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7:asf-site
  git commit --allow-empty -m "INFRA-10751 Empty commit"
  git push origin asf-site
  git checkout asf-site
  git branch -D asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7

Successful: HBase Generate Website

[Apache Jenkins Server]

Build status: Successful

If successful, the website and docs have been generated and the site has been 
updated automatically.
If failed, see https://builds.apache.org/job/hbase_generate_website/562/console

YOU DO NOT NEED TO DO THE FOLLOWING ANYMORE! It is here for informational 
purposes and shows what the Jenkins job does to push the site.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git
  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/562/artifact/website.patch.zip
 | funzip > 1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7.patch
  git fetch
  git checkout -b asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7 
origin/asf-site
  git am --whitespace=fix 1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7.patch
  git push origin asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7:asf-site
  git commit --allow-empty -m "INFRA-10751 Empty commit"
  git push origin asf-site
  git checkout asf-site
  git branch -D asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7

Successful: HBase Generate Website

[Apache Jenkins Server]

Build status: Successful

If successful, the website and docs have been generated and the site has been 
updated automatically.
If failed, see https://builds.apache.org/job/hbase_generate_website/561/console

YOU DO NOT NEED TO DO THE FOLLOWING ANYMORE! It is here for informational 
purposes and shows what the Jenkins job does to push the site.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git
  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/561/artifact/website.patch.zip
 | funzip > 1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7.patch
  git fetch
  git checkout -b asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7 
origin/asf-site
  git am --whitespace=fix 1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7.patch
  git push origin asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7:asf-site
  git commit --allow-empty -m "INFRA-10751 Empty commit"
  git push origin asf-site
  git checkout asf-site
  git branch -D asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7

Aborted: HBase Generate Website

[Apache Jenkins Server]

Build status: Aborted

If successful, the website and docs have been generated and the site has been 
updated automatically.
If failed, see https://builds.apache.org/job/hbase_generate_website/560/console

YOU DO NOT NEED TO DO THE FOLLOWING ANYMORE! It is here for informational 
purposes and shows what the Jenkins job does to push the site.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git
  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/560/artifact/website.patch.zip
 | funzip > ${GIT_SHA}.patch
  git fetch
  git checkout -b asf-site-${GIT_SHA} origin/asf-site
  git am --whitespace=fix $GIT_SHA.patch
  git push origin asf-site-${GIT_SHA}:asf-site
  git commit --allow-empty -m "INFRA-10751 Empty commit"
  git push origin asf-site
  git checkout asf-site
  git branch -D asf-site-${GIT_SHA}

Successful: HBase Generate Website

[Apache Jenkins Server]

Build status: Successful

If successful, the website and docs have been generated and the site has been 
updated automatically.

If this failed, and you need to apply these changes by hand and update the site 
manually, follow the instructions below. If the Jenkins job failed, skip to the 
bottom of this email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/559/artifact/website.patch.zip
 | funzip > 1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7.patch
  git fetch
  git checkout -b asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7 
origin/asf-site
  git am --whitespace=fix 1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7.patch

At this point, you can preview the changes by opening index.html or any of the 
other HTML pages in your local 
asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7 branch.

There are lots of spurious changes, such as timestamps and CSS styles in 
tables, so a generic git diff is not very useful. To see a list of files that 
have been added, deleted, renamed, changed type, or are otherwise interesting, 
use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these 
commands:

  git push origin asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7:asf-site
  git checkout asf-site
  git branch -D asf-site-1c4d9c8965952cbd17f0afdacbb0c0ac1e5bd1d7

Changes take a couple of minutes to be propagated. You can verify whether they 
have been propagated by looking at the Last Published date at the bottom of 
http://hbase.apache.org/. It should match the date in the index.html on the 
asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you pushed 
the site.



If failed, see https://builds.apache.org/job/hbase_generate_website/559/console

[jira] [Created] (HBASE-17862) Condition that always returns true

[JC (JIRA)]

JC created HBASE-17862:
--

 Summary: Condition that always returns true
 Key: HBASE-17862
 URL: https://issues.apache.org/jira/browse/HBASE-17862
 Project: HBase
  Issue Type: Bug
  Components: Client
Reporter: JC
Priority: Trivial


Hi

In recent github mirror of hbase, I've found the following code smell.

Path: 
hbase-client/src/main/java/org/apache/hadoop/hbase/filter/ColumnPaginationFilter.java

{code}
209 
210 ColumnPaginationFilter other = (ColumnPaginationFilter)o;
211 if (this.columnOffset != null) {
212   return this.getLimit() == this.getLimit() &&
213   Bytes.equals(this.getColumnOffset(), other.getColumnOffset());
214 }
{code}

It should be?
{code}
212   return this.getLimit() == other.getLimit() &&
{code}

This might be just a code smell as Bytes.equals can be enough for the return 
value but wanted to report just in case.

Thanks!




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HBASE-17861) Regionserver down when checking the permission of staging dir if hbase.rootdir is on S3

[Yi Liang (JIRA)]

Yi Liang created HBASE-17861:


 Summary: Regionserver down when checking the permission of staging 
dir if hbase.rootdir is on S3
 Key: HBASE-17861
 URL: https://issues.apache.org/jira/browse/HBASE-17861
 Project: HBase
  Issue Type: Bug
Reporter: Yi Liang
Assignee: Yi Liang


Found some issue, when set up HBASE-17437: Support specifying a WAL directory 
outside of the root directory.

The region server are  showdown when I add following config into hbase-site.xml 
hbase.rootdir = hdfs://xx/xx
hbase.wal.dir = s3a://xx//xx
hbase.coprocessor.region.classes = 
org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint
Error is below
{noformat}
org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint threw 
java.lang.IllegalStateException: Directory already exists but permissions 
aren't set to '-rwx--x--x'
{noformat}

The reason is that, when hbase enable securebulkload, hbase will create a 
folder in s3, it can not set above permission, because in s3, all files are 
listed as having full read/write permissions and all directories appear to have 
full rwx permissions.  See simulated permission section in 
https://docs.hortonworks.com/HDPDocuments/HDCloudAWS/HDCloudAWS-1.8.0/bk_hdcloud-aws/content/s3-s3aclient/index.html





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Moving 2.0 forward

[Andrew Purtell]

+1 on branching (yay!)

I have EC2 resources for running ITBLL etc.


On Thu, Mar 30, 2017 at 5:07 PM, Stack  wrote:

> Some notes on progress toward hbase2.
>
> Given that stability and performance are NOT emergent behaviors but rather
> projects unto themselves, my thought is that we commit all that we've
> agreed as core for hbase2 (see [1]), branch, and then work on stabilizing
> and perf rather than do stabilize, commit, and then branch. What this means
> in practice is that for features like Inmemory Compaction, we commit it
> defaulted 'on' ("BASIC" mode) which is what we want in hbase2. Should it
> prove problematic under test, we disable it before release.
>
> Are folks good w/ this mode? I ask because, in a few issues there are
> requests for proof that a master feature is 'stable' before commit. This is
> normally a healthy request only in master's case, it is hard to demonstrate
> stability given its current state.
>
> Other outstanding issues such as decisions about whether master hosts
> system tables only (by default), I'm thinking, we can work out post branch
> in alpha/betas before release.
>
> The awkward item is the long-pole Assignment Manager. This is an
> all-or-nothing affair. Here we are switching in a new Master core. While I
> think it fine that AMv2 is incomplete come branch time, those of us working
> on the new AM still need to demonstrate to you all that it basically
> viable.
>
> The point-of-no-return is commit of the patch in HBASE-14614. HBASE-14614
> (AMv2) is coming close to passing all unit tests. We'll spend some time
> running it on a cluster to make sure it fundamentally sound and will report
> back on our experience. There has been an ask for some dev doc and
> low-levels on how it works (in progress). Let satisfaction of these
> requests be blockers on commit. We'll put the HBASE-14614 commit up for a
> vote on dev list given its import.
>
> Branch will happen after HBASE-14614 goes in (or its rejection) with our
> first alpha soon after. Its looking like a week or two at least given how
> things have been going up to this.
>
> I intend to start in on hbase2 stability/perf projects after we branch.
>
> Interested in any thoughts you all might have on the above (Would also
> appreciate updates on state in [1] if you are a feature owner).
>
> Thanks,
> St.Ack
>
> 1. https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4
> z9iEu_ktczrlKHK8N4SZzs/edit#
>
>
>
> On Sat, Mar 11, 2017 at 5:32 PM, Josh Elser  wrote:
>
> >
> > Stack wrote:
> >
> >> On Tue, Mar 7, 2017 at 1:51 PM, Josh Elser  wrote:
> >>
> >> Thanks for pulling in the FS Quotas work, Stack. I'm trying to cross the
> >>> last T's and dot the last I's.
> >>>
> >>> The biggest thing I know I need to do still is to write a new chapter
> to
> >>> the book. After that, I'd start entertaining larger reviews/discussions
> >>> to
> >>> merge the feature into master. Anyone with free time (giggles) is more
> >>> than
> >>> welcome to start perusing :)
> >>>
> >>>
> >>> Out of interest, this could come in after 2.0 Josh? Any 2.0 specific
> >> needs
> >> to make this work?
> >>
> >> Meantime, updated the 2.0 doc 1.
> >>
> >> Thanks Josh,
> >> St.Ack
> >>
> >> 1.
> >> https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9i
> >> Eu_ktczrlKHK8N4SZzs/edit#
> >>
> >>
> > Nope, no need to block 2.0 on this one (given the other, related
> chatter).
> > Would be nice to get it in, but I completely understand if it slips :)
> >
> > Thanks for updating the doc for me!
> >
>



-- 
Best regards,

   - Andy

If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)

Aborted: HBase Generate Website

[Apache Jenkins Server]

Build status: Aborted

If successful, the website and docs have been generated and the site has been 
updated automatically.

If this failed, and you need to apply these changes by hand and update the site 
manually, follow the instructions below. If the Jenkins job failed, skip to the 
bottom of this email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/558/artifact/website.patch.zip
 | funzip > ${GIT_SHA}.patch
  git fetch
  git checkout -b asf-site-${GIT_SHA} origin/asf-site
  git am --whitespace=fix $GIT_SHA.patch

At this point, you can preview the changes by opening index.html or any of the 
other HTML pages in your local asf-site-${GIT_SHA} branch.

There are lots of spurious changes, such as timestamps and CSS styles in 
tables, so a generic git diff is not very useful. To see a list of files that 
have been added, deleted, renamed, changed type, or are otherwise interesting, 
use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these 
commands:

  git push origin asf-site-${GIT_SHA}:asf-site
  git checkout asf-site
  git branch -D asf-site-${GIT_SHA}

Changes take a couple of minutes to be propagated. You can verify whether they 
have been propagated by looking at the Last Published date at the bottom of 
http://hbase.apache.org/. It should match the date in the index.html on the 
asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you pushed 
the site.



If failed, see https://builds.apache.org/job/hbase_generate_website/558/console

[jira] [Created] (HBASE-17860) Implement secure native client connection

[Ted Yu (JIRA)]

Ted Yu created HBASE-17860:
--

 Summary: Implement secure native client connection
 Key: HBASE-17860
 URL: https://issues.apache.org/jira/browse/HBASE-17860
 Project: HBase
  Issue Type: Sub-task
Reporter: Ted Yu
Assignee: Ted Yu
Priority: Critical


So far, the native client communicates with insecure cluster.

This JIRA is to add secure connection support for native client using Cyrus 
library.
The work is based on earlier implementation and is redone via wangle and folly 
frameworks.

Thanks to [~devaraj] who started the initiative.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Remove invalid '2.0' and '2.0..' verions from jira

[Josh Elser]

Just checked and I don't see 'em there anymore. I assume someone else 
has already done this :)


Enis Söztutar wrote:

Thanks for the cleanup. Indeed we should remove these from jira admin so
that they don't show up in auto-fill.

Enis

On Fri, Mar 31, 2017 at 8:34 AM, Stack  wrote:


On Thu, Mar 30, 2017 at 7:02 PM, Duo Zhang  wrote:


There are plenty of issues which are assigned a version called '2.0' OR
'2.0..'.

The latter one is a typo I think. And for the former one, I think we

should

claim again that the first release for 2.x release line is 2.0.0, not

2.0.

So do not use 2.0 anymore. We committers should be careful when opening
issues or resolving issues.

Thanks.


Thanks Duo. I could admin removing these mis-versions?
St.Ack

Re: Remove invalid '2.0' and '2.0..' verions from jira

[Enis Söztutar]

Thanks for the cleanup. Indeed we should remove these from jira admin so
that they don't show up in auto-fill.

Enis

On Fri, Mar 31, 2017 at 8:34 AM, Stack  wrote:

> On Thu, Mar 30, 2017 at 7:02 PM, Duo Zhang  wrote:
>
> > There are plenty of issues which are assigned a version called '2.0' OR
> > '2.0..'.
> >
> > The latter one is a typo I think. And for the former one, I think we
> should
> > claim again that the first release for 2.x release line is 2.0.0, not
> 2.0.
> > So do not use 2.0 anymore. We committers should be careful when opening
> > issues or resolving issues.
> >
> > Thanks.
> >
>
> Thanks Duo. I could admin removing these mis-versions?
> St.Ack
>

Re: Remove invalid '2.0' and '2.0..' verions from jira

[Stack]

On Thu, Mar 30, 2017 at 7:02 PM, Duo Zhang  wrote:

> There are plenty of issues which are assigned a version called '2.0' OR
> '2.0..'.
>
> The latter one is a typo I think. And for the former one, I think we should
> claim again that the first release for 2.x release line is 2.0.0, not 2.0.
> So do not use 2.0 anymore. We committers should be careful when opening
> issues or resolving issues.
>
> Thanks.
>

Thanks Duo. I could admin removing these mis-versions?
St.Ack

Re: Moving 2.0 forward

[Stack]

On Thu, Mar 30, 2017 at 6:22 PM, Enis Söztutar  wrote:

> Thanks Stack for the update. +1 on branching as soon as possible. For
> getting aforementioned stability, we need to start rejecting patches/
> features from 2.0.0. Branching early gives us the option of gradually
> working towards that, but also does not block new development to happen on
> master. I think the most important job for the RM is to say NO to
> improvement jiras going into 2.0, if they have nothing to do with the
> agreed upon goals of the release.
>
>
Agreed (I've been practicing with a mirror).

And thanks Yu Li for volunteering to help with stability (a few others have
expressed interest too).

St.Ack



> Enis
>
> On Thu, Mar 30, 2017 at 5:07 PM, Stack  wrote:
>
> > Some notes on progress toward hbase2.
> >
> > Given that stability and performance are NOT emergent behaviors but
> rather
> > projects unto themselves, my thought is that we commit all that we've
> > agreed as core for hbase2 (see [1]), branch, and then work on stabilizing
> > and perf rather than do stabilize, commit, and then branch. What this
> means
> > in practice is that for features like Inmemory Compaction, we commit it
> > defaulted 'on' ("BASIC" mode) which is what we want in hbase2. Should it
> > prove problematic under test, we disable it before release.
> >
> > Are folks good w/ this mode? I ask because, in a few issues there are
> > requests for proof that a master feature is 'stable' before commit. This
> is
> > normally a healthy request only in master's case, it is hard to
> demonstrate
> > stability given its current state.
> >
> > Other outstanding issues such as decisions about whether master hosts
> > system tables only (by default), I'm thinking, we can work out post
> branch
> > in alpha/betas before release.
> >
> > The awkward item is the long-pole Assignment Manager. This is an
> > all-or-nothing affair. Here we are switching in a new Master core. While
> I
> > think it fine that AMv2 is incomplete come branch time, those of us
> working
> > on the new AM still need to demonstrate to you all that it basically
> > viable.
> >
> > The point-of-no-return is commit of the patch in HBASE-14614. HBASE-14614
> > (AMv2) is coming close to passing all unit tests. We'll spend some time
> > running it on a cluster to make sure it fundamentally sound and will
> report
> > back on our experience. There has been an ask for some dev doc and
> > low-levels on how it works (in progress). Let satisfaction of these
> > requests be blockers on commit. We'll put the HBASE-14614 commit up for a
> > vote on dev list given its import.
> >
> > Branch will happen after HBASE-14614 goes in (or its rejection) with our
> > first alpha soon after. Its looking like a week or two at least given how
> > things have been going up to this.
> >
> > I intend to start in on hbase2 stability/perf projects after we branch.
> >
> > Interested in any thoughts you all might have on the above (Would also
> > appreciate updates on state in [1] if you are a feature owner).
> >
> > Thanks,
> > St.Ack
> >
> > 1. https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4
> > z9iEu_ktczrlKHK8N4SZzs/edit#
> >
> >
> >
> > On Sat, Mar 11, 2017 at 5:32 PM, Josh Elser  wrote:
> >
> > >
> > > Stack wrote:
> > >
> > >> On Tue, Mar 7, 2017 at 1:51 PM, Josh Elser  wrote:
> > >>
> > >> Thanks for pulling in the FS Quotas work, Stack. I'm trying to cross
> the
> > >>> last T's and dot the last I's.
> > >>>
> > >>> The biggest thing I know I need to do still is to write a new chapter
> > to
> > >>> the book. After that, I'd start entertaining larger
> reviews/discussions
> > >>> to
> > >>> merge the feature into master. Anyone with free time (giggles) is
> more
> > >>> than
> > >>> welcome to start perusing :)
> > >>>
> > >>>
> > >>> Out of interest, this could come in after 2.0 Josh? Any 2.0 specific
> > >> needs
> > >> to make this work?
> > >>
> > >> Meantime, updated the 2.0 doc 1.
> > >>
> > >> Thanks Josh,
> > >> St.Ack
> > >>
> > >> 1.
> > >> https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9i
> > >> Eu_ktczrlKHK8N4SZzs/edit#
> > >>
> > >>
> > > Nope, no need to block 2.0 on this one (given the other, related
> > chatter).
> > > Would be nice to get it in, but I completely understand if it slips :)
> > >
> > > Thanks for updating the doc for me!
> > >
> >
>

[jira] [Created] (HBASE-17859) ByteBufferUtils#compareTo is wrong

[Chia-Ping Tsai (JIRA)]

Chia-Ping Tsai created HBASE-17859:
--

 Summary: ByteBufferUtils#compareTo is wrong
 Key: HBASE-17859
 URL: https://issues.apache.org/jira/browse/HBASE-17859
 Project: HBase
  Issue Type: Bug
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
 Fix For: 2.0.0


buf2.get( i ) & 0xFF; -> buf2.get(j) & 0xFF;
{noformat}
  public static int compareTo(byte [] buf1, int o1, int l1, ByteBuffer buf2, 
int o2, int l2) {
   // 
int end1 = o1 + l1;
int end2 = o2 + l2;
for (int i = o1, j = o2; i < end1 && j < end2; i++, j++) {
  int a = buf1[i] & 0xFF;
  int b = buf2.get(i) & 0xFF;
  if (a != b) {
return a - b;
  }
}
return l1 - l2;
  }
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Successful: HBase Generate Website

[Apache Jenkins Server]

Build status: Successful

If successful, the website and docs have been generated. To update the live 
site, follow the instructions below. If failed, skip to the bottom of this 
email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/557/artifact/website.patch.zip
 | funzip > a9682ca5dc46a74edca3da630560fbaf5d0cf38b.patch
  git fetch
  git checkout -b asf-site-a9682ca5dc46a74edca3da630560fbaf5d0cf38b 
origin/asf-site
  git am --whitespace=fix a9682ca5dc46a74edca3da630560fbaf5d0cf38b.patch

At this point, you can preview the changes by opening index.html or any of the 
other HTML pages in your local 
asf-site-a9682ca5dc46a74edca3da630560fbaf5d0cf38b branch.

There are lots of spurious changes, such as timestamps and CSS styles in 
tables, so a generic git diff is not very useful. To see a list of files that 
have been added, deleted, renamed, changed type, or are otherwise interesting, 
use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these 
commands:

  git commit --allow-empty -m "Empty commit" # to work around a current ASF 
INFRA bug
  git push origin asf-site-a9682ca5dc46a74edca3da630560fbaf5d0cf38b:asf-site
  git checkout asf-site
  git branch -D asf-site-a9682ca5dc46a74edca3da630560fbaf5d0cf38b

Changes take a couple of minutes to be propagated. You can verify whether they 
have been propagated by looking at the Last Published date at the bottom of 
http://hbase.apache.org/. It should match the date in the index.html on the 
asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you pushed 
the site.



If failed, see https://builds.apache.org/job/hbase_generate_website/557/console

Re: Moving 2.0 forward

[Yu Li]

+1 on early branch, and count me in for the coming stability/perf projects
(smile).

Best Regards,
Yu

On 31 March 2017 at 09:22, Enis Söztutar  wrote:

> Thanks Stack for the update. +1 on branching as soon as possible. For
> getting aforementioned stability, we need to start rejecting patches/
> features from 2.0.0. Branching early gives us the option of gradually
> working towards that, but also does not block new development to happen on
> master. I think the most important job for the RM is to say NO to
> improvement jiras going into 2.0, if they have nothing to do with the
> agreed upon goals of the release.
>
> Enis
>
> On Thu, Mar 30, 2017 at 5:07 PM, Stack  wrote:
>
> > Some notes on progress toward hbase2.
> >
> > Given that stability and performance are NOT emergent behaviors but
> rather
> > projects unto themselves, my thought is that we commit all that we've
> > agreed as core for hbase2 (see [1]), branch, and then work on stabilizing
> > and perf rather than do stabilize, commit, and then branch. What this
> means
> > in practice is that for features like Inmemory Compaction, we commit it
> > defaulted 'on' ("BASIC" mode) which is what we want in hbase2. Should it
> > prove problematic under test, we disable it before release.
> >
> > Are folks good w/ this mode? I ask because, in a few issues there are
> > requests for proof that a master feature is 'stable' before commit. This
> is
> > normally a healthy request only in master's case, it is hard to
> demonstrate
> > stability given its current state.
> >
> > Other outstanding issues such as decisions about whether master hosts
> > system tables only (by default), I'm thinking, we can work out post
> branch
> > in alpha/betas before release.
> >
> > The awkward item is the long-pole Assignment Manager. This is an
> > all-or-nothing affair. Here we are switching in a new Master core. While
> I
> > think it fine that AMv2 is incomplete come branch time, those of us
> working
> > on the new AM still need to demonstrate to you all that it basically
> > viable.
> >
> > The point-of-no-return is commit of the patch in HBASE-14614. HBASE-14614
> > (AMv2) is coming close to passing all unit tests. We'll spend some time
> > running it on a cluster to make sure it fundamentally sound and will
> report
> > back on our experience. There has been an ask for some dev doc and
> > low-levels on how it works (in progress). Let satisfaction of these
> > requests be blockers on commit. We'll put the HBASE-14614 commit up for a
> > vote on dev list given its import.
> >
> > Branch will happen after HBASE-14614 goes in (or its rejection) with our
> > first alpha soon after. Its looking like a week or two at least given how
> > things have been going up to this.
> >
> > I intend to start in on hbase2 stability/perf projects after we branch.
> >
> > Interested in any thoughts you all might have on the above (Would also
> > appreciate updates on state in [1] if you are a feature owner).
> >
> > Thanks,
> > St.Ack
> >
> > 1. https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4
> > z9iEu_ktczrlKHK8N4SZzs/edit#
> >
> >
> >
> > On Sat, Mar 11, 2017 at 5:32 PM, Josh Elser  wrote:
> >
> > >
> > > Stack wrote:
> > >
> > >> On Tue, Mar 7, 2017 at 1:51 PM, Josh Elser  wrote:
> > >>
> > >> Thanks for pulling in the FS Quotas work, Stack. I'm trying to cross
> the
> > >>> last T's and dot the last I's.
> > >>>
> > >>> The biggest thing I know I need to do still is to write a new chapter
> > to
> > >>> the book. After that, I'd start entertaining larger
> reviews/discussions
> > >>> to
> > >>> merge the feature into master. Anyone with free time (giggles) is
> more
> > >>> than
> > >>> welcome to start perusing :)
> > >>>
> > >>>
> > >>> Out of interest, this could come in after 2.0 Josh? Any 2.0 specific
> > >> needs
> > >> to make this work?
> > >>
> > >> Meantime, updated the 2.0 doc 1.
> > >>
> > >> Thanks Josh,
> > >> St.Ack
> > >>
> > >> 1.
> > >> https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9i
> > >> Eu_ktczrlKHK8N4SZzs/edit#
> > >>
> > >>
> > > Nope, no need to block 2.0 on this one (given the other, related
> > chatter).
> > > Would be nice to get it in, but I completely understand if it slips :)
> > >
> > > Thanks for updating the doc for me!
> > >
> >
>

[jira] [Created] (HBASE-17858) Update refguide about the IS annotation if necessary

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-17858:
-

 Summary: Update refguide about the IS annotation if necessary
 Key: HBASE-17858
 URL: https://issues.apache.org/jira/browse/HBASE-17858
 Project: HBase
  Issue Type: Sub-task
  Components: API, documentation
Affects Versions: 2.0.0
Reporter: Duo Zhang
 Fix For: 2.0.0






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HBASE-17857) Remove IS annotations from IA.Public classes

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-17857:
-

 Summary: Remove IS annotations from IA.Public classes
 Key: HBASE-17857
 URL: https://issues.apache.org/jira/browse/HBASE-17857
 Project: HBase
  Issue Type: Sub-task
  Components: API
Affects Versions: 2.0.0
Reporter: Duo Zhang
Assignee: Duo Zhang
 Fix For: 2.0.0






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Remove invalid '2.0' and '2.0..' verions from jira

[Chia-Ping Tsai]

copy that. Thanks for the reminder.

On 2017-03-31 10:02 (+0800), Duo Zhang  wrote: 
> There are plenty of issues which are assigned a version called '2.0' OR
> '2.0..'.
> 
> The latter one is a typo I think. And for the former one, I think we should
> claim again that the first release for 2.x release line is 2.0.0, not 2.0.
> So do not use 2.0 anymore. We committers should be careful when opening
> issues or resolving issues.
> 
> Thanks.
>