Time for 1.1.10?

[Nick Dimiduk]

Hey there,

It's been about a month since 1.1.9. However there's only 11 commits to
branch-1.1 since that time. Based on commit messages, there's only [0], [1]
that I think would make someone really impatient for a fix. [0] is marked
'Critical', so I'm on the fence. Unless someone speaks up, I'm thinking
I'll wait for 1.1.10 until after the 1.3.1 release, give a chance for some
backports to trickle down. Any objections?

-n

[0]: HBASE-17717 Explicitly use "sasl" ACL scheme for hbase superuser
[1]: HBASE-17682 Region stuck in merging_new state indefinitely

Re: [DISCUSS] More Shading

[Nick Dimiduk]

> This effort is about our internals. We have a mess of other components all
> up inside us such as HDFS, etc., each with their own sets of dependencies
> many of which we have in common. This project t is about making it so we
> can upgrade at a rate independent of when our upstreamers choose to
change.

Pardon as I try to get a handle on the intention behind this thread.

If the above quote is true, then I think what we want is a set of shaded
Hadoop client libs that we can depend on so as to not get all the
transitive deps. Hadoop doesn't provide it, but we could do so ourselves
with (yet another) module in our project. Assuming, that is, the upstream
client interfaces are well defined and don't leak stuff we care about. It
also creates a terrible nightmare for anyone downstream of us who
repackages HBase. The whole thing is extremely error-prone, because there's
not very good tooling for this. Realistically, we end up with a combination
of the enforcer plugin and maybe our own custom plugin to ensure clean
transitive dependencies...

I guess the suggestion of the external repo containing our shaded fork of
everything we depend on allows us to continue to compile, run on Hadoop's
transitive dependency list w.o actually using any of it, I have that right?
How would we version this thing?

Between these two choices, I prefer the former as a "more correct"
solution, but it depends entirely on how clean of a shaded hadoop we can
reliably produce inline our build.

On Tue, Apr 11, 2017 at 1:03 PM, Stack  wrote:

> On Tue, Apr 11, 2017 at 10:23 AM, York, Zach  wrote:
>
> > Should we allow dependent projects (such as Phoenix) to weigh in on this
> > issue since they are likely going to be the ones that benefit/are
> effected?
> >
> > I dumped a pointer to here into dev@phoenix.
> St.Ack
>
>
>
> > On 4/11/17, 10:17 AM, "York, Zach"  wrote:
> >
> > +1 (non-binding)
> >
> > This sounds like a good idea to me!
> >
> > Zach
> >
> > On 4/11/17, 9:48 AM, "saint@gmail.com on behalf of Stack" <
> > saint@gmail.com on behalf of st...@duboce.net> wrote:
> >
> > Let me revive this thread.
> >
> > Recall, we are stuck on old or particular versions of critical
> > libs. We are
> > unable to update because our versions will clash w/ versions from
> > upstreamer hadoop2.7/2.8/3.0/spark, etc. We have a shaded client.
> > We need
> > to message downstreamers that they should use it going forward.
> > This will
> > help going forward but it will not inoculate our internals nor an
> > existing
> > context where we'd like to be a compatible drop-in.
> >
> > We could try hackery filtering transitive includes up in poms for
> > each
> > version of hadoop/spark that we support but in the end, its a
> > bunch of
> > effort, hard to test, and we are unable to dictate the CLASSPATH
> > order in
> > all situations.
> >
> > We could try some shading voodoo inline w/ build. Because shading
> > is a
> > post-package step and because we are modularized and shading
> > includes the
> > shaded classes in the artifact produced, we'd end up w/ multiple
> > copies of
> > guava/netty/etc. classes, an instance per module that makes a
> > reference.
> >
> > Lets do Sean's idea of a pre-build step where we package and
> > relocate
> > ('shade') critical dependencies (Going by the thread above, Ram,
> > Anoop, and
> > Andy seems good w/ general idea).
> >
> > In implementation, we (The HBase PMC) would ask for a new repo
> > [1]. In here
> > we'd create a new mvn project. This project would produce a
> single
> > artifact
> > (jar) called hbase-dependencies or hbase-3rdparty or
> > hbase-shaded-3rdparty
> > libs. In it would be relocated core libs such as guava and netty
> > (and maybe
> > protobuf). We'd publish this artifact and then have hbase depend
> > on it
> > changing all references to point at the relocation: e.g. rather
> > than import
> > com.google.common.collect.Maps, we'd import
> > org.apache.hadoop.hbase.com.google.common.collect.Maps.
> >
> > We (The HBase PMC) will have to make releases of this new
> artifact
> > and vote
> > on them. I think it will be a relatively rare event.
> >
> > I'd be up for doing the first cut if folks are game.
> >
> > St.Ack
> >
> >
> > 1. URL via Sean but for committers to view only:
> > https://reporeq.apache.org/
> >
> > On Sun, Oct 2, 2016 at 10:29 PM, ramkrishna vasudevan <
> > ramkrishna.s.vasude...@gmail.com> wrote:
> >
> > > +1 for Sean's ideas. Bundling all the dependent libraries and
> > shading them
> > > into one jar and HBase referring to it makes sense and should
> > avoid some of
> > > the pain in terms of IDE usage. Stack's doc clearly talks about
> > the IDE
> > > issues that

Re: [DISCUSS] More Shading

[Nick Dimiduk]

On Wed, Apr 12, 2017 at 8:28 AM Josh Elser  wrote:

>
>
> Sean Busbey wrote:
> > On Tue, Apr 11, 2017 at 11:43 PM Nick Dimiduk
> wrote:
> >
> >>> This effort is about our internals. We have a mess of other components
> >> all
> >>> up inside us such as HDFS, etc., each with their own sets of
> dependencies
> >>> many of which we have in common. This project t is about making it so
> we
> >>> can upgrade at a rate independent of when our upstreamers choose to
> >> change.
> >>
> >> Pardon as I try to get a handle on the intention behind this thread.
> >>
> >> If the above quote is true, then I think what we want is a set of shaded
> >> Hadoop client libs that we can depend on so as to not get all the
> >> transitive deps. Hadoop doesn't provide it, but we could do so ourselves
> >> with (yet another) module in our project. Assuming, that is, the
> upstream
> >> client interfaces are well defined and don't leak stuff we care about.
> It
> >> also creates a terrible nightmare for anyone downstream of us who
> >> repackages HBase. The whole thing is extremely error-prone, because
> there's
> >> not very good tooling for this. Realistically, we end up with a
> combination
> >> of the enforcer plugin and maybe our own custom plugin to ensure clean
> >> transitive dependencies...
> >>
> >>
> > Hadoop does provide a shaded client as of the 3.0.0* release line. We
> could
> > push as a community for a version of that for Hadoop's branch-2.
> >
> > Unfortunately, that shaded client won't help where we're reaching into
> the
> > guts of Hadoop (like our reliance on their web stuff).
>
> Well put, Nick.
>
> With Sean's point about the Hadoop shaded client, it seems to me that we
> have things which could be pursued in parallel:
>
> 1) Roadmap to Hadoop3 (and shaded hdfs client).
> 2) Identify components which we use from Hadoop, for each component:
>2a) Work with Hadoop to isolate that component from other cruft (best
> example is the Configuration class -- you get something like 8MB of
> "jar" just to parse an xml file).
>2b) Pull the implementation into HBase, removing dependency from
> Hadoop entirely.
>
> I think that both of these can/should be done in parallel to the
> isolation of the dependencies which HBase requires (isolating ourselves
> from upstream, and isolating downstream from us).


Hang on, these are two different concerns.

Isolating ourselves from Hadoop follows the line of thought around Hadoop's
shaded client jars. If we must have this for HBase 2.0/Hadoop 2.8, we can
probably backport their efforts as modules in our own build. See my early
comment about this being error prone for folks who re-package us. Either
way, it's time we firm up the boundaries between us and Hadoop.

Isolating our clients from our deps is best served by our shaded modules.
What do you think about turning things on their head: for 2.0 the
hbase-client jar is the shaded artifact by default, not the other way
around? We have cleanup to get our deps out of our public interfaces in
order to make this work.

This proposal of an external shaded dependencies module sounds like an
attempt to solve both concerns at once. It would isolate ourselves from
Hadoop's deps, and it would isolate our clients from our deps. However, it
doesn't isolate our clients from Hadoop's deps, so our users don't really
gain anything from it. I also argue that it creates an unreasonable release
engineering burden on our project. I'm also not clear on the implications
to downstreamers who extend us with coprocessors.

>

Re: ANNOUNCE: Yu Li joins the Apache HBase PMC

[Nick Dimiduk]

Congratulations Yu and thanks a lot! Keep up the good work!

On Fri, Apr 14, 2017 at 7:22 AM Anoop John  wrote:

> On behalf of the Apache HBase PMC I"m pleased to announce that Yu Li
> has accepted our invitation to become a PMC member on the Apache HBase
> project. He has been an active contributor to HBase for past many
> years. Looking forward for
> many more contributions from him.
>
> Welcome to the PMC, Yu Li...
>
>
> -Anoop-
>

Re: [DISCUSS] More Shading

[Nick Dimiduk]

Related: very relevant concerns have been raised in the comments over
on HADOOP-11656.
See Christopher Tubbs's recent remarks.

On Thu, Apr 13, 2017 at 4:46 PM, Josh Elser  wrote:

>
>
> Stack wrote:
>
>> On Wed, Apr 12, 2017 at 8:22 AM, Josh Elser  wrote:
>> 
>>
>> This makes me wonder if we could construct source jars just the same as
>>> we're creating shaded jars. Google has lead me to [2][3], but I've never
>>> tried either. The latter option seems to be acknowledging that the source
>>> might not actually compile, but the package names would at least be
>>> correct.
>>>
>>> I think this would be a good early experiment which, if it does work out,
>>> removes the only acknowledged "hole" in the current plan.
>>>
>>>
>>> Mighty Josh.
>>
>> As it happens, the 'createSources' you cite is currently in use by our
>> hbase-protocol-shaded module for the specific purpose of keeping our
>> IDE'rs
>> happy; we relocate protobuf itself so we can have pb3.2 and pb2.5 on our
>> CLASSPATH but IDEs don't complain because the src for the relocated pb is
>> checked-in to our codebase.
>>
>
> Aha! Wizards are ahead of me on the path already :)
>
>
> Here's more if interested:
>>
>> All modules that make use of protos by convention require a 'pre-build'
>> step. Generally, the pre-build is required if you add or mod .proto files.
>> At pre-build we generate class files from the amended .protos and then
>> check-in the product. See the README in each of our proto-carrying
>> modules.
>>
>> In the hbase-protocol-shaded case, we abuse the pre-build notion so we can
>> house an internal pb version, one that does not agree w/ hadoops nor w/
>> that used by our CPs describing Endpoint services.  We do as follows (the
>> order may not be exact in below):
>>
>>   * Generate class files from protos
>>   * Shade the built artifact (with the createSource flag set).
>>   * Unjar the artifact which has generated proto and protobuf src classes
>> in
>> it
>>   * Apply a few patches to protobuf to support offheap work (stuff we need
>> to push back up to pb)
>>   * Overlay our current protobuf src w/ the new version in the src tree
>> -- a
>> big no-no (smile).
>>
>> You then check it all in
>>
>> It has been suggested we undo these hokey pre-build steps and just
>> generate
>> classes from protobuf inline w/ the main build. A plugin we just figured
>> makes this possible since it provides the platform-appropriate protoc
>> (org.xolstice.maven.plugins). We could do the simplification currently for
>> all but the hbase-protocol-shaded module because of the above jujitsu. One
>> thought is that if we had a pre-build artifact as is being suggested in
>> this thread, I could move the patched pb there and purge the pre-build
>> step
>> everywhere.
>>
>
> The xolstice plugin has been working well for me elsewhere so far. +1
>
> I think we're speaking the same language. My realization was that,
> hopefully, we could automatically create that pre-built artifact via Maven
> magic instead of having a human copy source files around.
>
> I think pushing this part forward with some code is the next logical step.
> Seems to be consensus about taking our known internal dependencies and
> performing this shade magic.
>
> Don't want to stomp on your worries, Nick. I think your worries are more
> about the presentation to downstream and we're in agreement about isolating
> our internal deps with the described approach?
>
>
> Thanks,
>> St.Ack
>>
>>
>>
>> We (The HBase PMC) will have to make releases of this new artifact and
>>> vote
>>>
 on them. I think it will be a relatively rare event.

 I'd be up for doing the first cut if folks are game.

 St.Ack


 1. URL via Sean but for committers to view only:
 https://reporeq.apache.org/


 [2] https://maven.apache.org/plugins/maven-shade-plugin/shade-
>>> mojo.html#createSourcesJar
>>> [3] https://maven.apache.org/plugins/maven-shade-plugin/shade-
>>> mojo.html#shadeSourcesContent
>>>
>>>
>>

Re: Time for 1.1.10?

[Nick Dimiduk]

1.3.1 appears to be (mostly?) through the paces and there's been no further
activity on branch-1.1 since my original mail. RC in flight.

On Tue, Apr 4, 2017 at 9:19 PM, Andrew Purtell 
wrote:

> If you'd like to release I will certainly vote on the candidate. If that
> informs your opinion on spinning a release candidate.
>
>
> > On Apr 4, 2017, at 7:57 PM, Nick Dimiduk  wrote:
> >
> > Hey there,
> >
> > It's been about a month since 1.1.9. However there's only 11 commits to
> > branch-1.1 since that time. Based on commit messages, there's only [0],
> [1]
> > that I think would make someone really impatient for a fix. [0] is marked
> > 'Critical', so I'm on the fence. Unless someone speaks up, I'm thinking
> > I'll wait for 1.1.10 until after the 1.3.1 release, give a chance for
> some
> > backports to trickle down. Any objections?
> >
> > -n
> >
> > [0]: HBASE-17717 Explicitly use "sasl" ACL scheme for hbase superuser
> > [1]: HBASE-17682 Region stuck in merging_new state indefinitely
>

Re: [DISCUSS] More Shading

[Nick Dimiduk]

On Wed, Apr 12, 2017 at 2:30 PM, Stack  wrote:

> > >> If the above quote is true, then I think what we want is a set of
> > shaded
> > > >> Hadoop client libs that we can depend on so as to not get all the
> > > >> transitive deps. Hadoop doesn't provide it, but we could do so
> > ourselves
> > > >> with (yet another) module in our project. Assuming, that is, the
> > > upstream
> > > >> client interfaces are well defined and don't leak stuff we care
> about.
> >
>
>
> We should do this too (I think you've identified the big 'if' w/ the above
> identified assumption). As you say later, "... it's time we firm up the
> boundaries between us and Hadoop.". There is some precedent with
> hadoop-compat-* modules. Hadoop would be relocated?
>

Ideally we'd relocate any parts of Hadoop that are not part of our public
contract. Not sure if there's an intersection between "ideal" and
"practical" though.

Spitballing, IIUC, I think this would be a big job (once per version and
> the vagaries of hadoop/spark) with no guarantee of success on other end
> because of assumption you call out. Do I have this right?
>

Yeah you have my meaning. My argument is not whether we should shade but
rather how we make it a maintainable deployment tool for our team of
volunteers. Hence interest in compatibility verification tools like we do
with our api compatibility tools.

> Isolating our clients from our deps is best served by our shaded modules.
> > What do you think about turning things on their head: for 2.0 the
> > hbase-client jar is the shaded artifact by default, not the other way
> > around? We have cleanup to get our deps out of our public interfaces in
> > order to make this work.
> >
> >
> We should do this at least going forward. hbase2 is the opportunity.
> Testing and doc is all that is needed? I added it to our hbase2 description
> doc as a deliverable (though not a blocker).
>

I've not tried to consume these efforts. A reasonable test-case to see if
these are ready for prime-time would be to try rebuilding one of the more
complex downstream projects (i.e, Phoenix, Trafodion, Splice) using the
shaded jars and see how bad the diff is.

> This proposal of an external shaded dependencies module sounds like an
> > attempt to solve both concerns at once. It would isolate ourselves from
> > Hadoop's deps, and it would isolate our clients from our deps. However,
> it
> > doesn't isolate our clients from Hadoop's deps, so our users don't really
> > gain anything from it. I also argue that it creates an unreasonable
> release
> > engineering burden on our project. I'm also not clear on the implications
> > to downstreamers who extend us with coprocessors.
> >
>
>
> Other than a missing 'quick-fix' descriptor, you call what is proposed well
> except where you think the prebuild will be burdensome. Here I think
> otherwise as I think releases will be rare, there is nought 'new' in a
> release but packaged 3rd-party libs, and verification/vote by PMCers should
> be a simple affair.
>

Maybe it's not such a burden? If the 2.0 and 3.0 RM's are brave and true,
it's worth a go.

Do you agree that the fixing-what-we-leak-of-hadoop-to-downstreamers is
> distinct from the narrower task proposed here where we are trying to
> unhitch ourselves of the netty/guava hadoop uses? (Currently we break
> against hadoop3 because of netty incompat., HADOOP-13866, which we might be
> able to solve w/ exclusions.but).
>
> The two tasks can be run in parallel?
>

Indeed, they seem distinct but quite related.

For CPs, they should bring their own bedding and towels and not be trying
> to use ours. On the plus-side, we could upgrade core 3rd-party libs and the
> CP would keep working.
>

All of this sounds like an ideal state.

[VOTE] First release candidate for HBase 1.1.10 (RC0) is available

[Nick Dimiduk]

I'm happy to announce the first release candidate of HBase 1.1.10
(HBase-1.1.10RC0) is available for download at
https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.10RC0/

Maven artifacts are also available in the staging repository
https://repository.apache.org/content/repositories/orgapachehbase-1167

Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
available in the Apache keys directory
https://people.apache.org/keys/committer/ndimiduk.asc and in our KEYS file
http://www-us.apache.org/dist/hbase/KEYS.

Please note that this signing key is set to expire at the end of this
month. I will be taking steps to extend its expiration date. This should be
transparent, but may cause some hiccups.

There's also a signed tag for this release at
https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=4a7f2062f5776d6423d19f6d88bc4161c33ccd0c

The detailed source and binary compatibility report vs 1.1.9 has been
published for your review, at
https://home.apache.org/~ndimiduk/1.1.9_1.1.10RC0_compat_report.html

HBase 1.1.10 is the tenth patch release in the HBase 1.1 line, continuing
on the theme of bringing a stable, reliable database to the Hadoop and
NoSQL communities. This release includes over 10 bug fixes since the 1.1.9
release. Notable correctness fixes include HBASE-17675, HBASE-17682,
HBASE-17287, and HBASE-17717.

The full list of fixes included in this release is available at
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310753&version=12339651
and and in the CHANGES.txt file included in the distribution.

Please try out this candidate and vote +/-1 by 23:59 Pacific time on
Tuesday, 2017-04-24 as to whether we should release these artifacts as
HBase 1.1.10.

Thanks,
Nick

Re: [VOTE] First release candidate for HBase 1.1.10 (RC0) is available

[Nick Dimiduk]

+1

- verified tarballs vs public key on people.apache.org.
- extracted bin tgz:
  - inspect structure. look good.
  - with jdk1.8.0_65:
- run LoadTestTool against standalone bin tgz with FAST_DIFF block
encoder and ROWCOL blooms. No issues, logs look good.
- poked around webUI. looks good.
  - load the site, browsed book.
- extracted src tgz:
  - inspect structure. look good.
  - run LoadTestTool against standalone built from src tgz with FAST_DIFF
block encoder and ROWCOL blooms. No issues, logs look good.
  - poked around webUI. looks good.
- ran the hbase-downstreamer project vs. the staged maven repository. tests
pass.

On Tue, Apr 18, 2017 at 10:00 PM, Nick Dimiduk  wrote:

> I'm happy to announce the first release candidate of HBase 1.1.10
> (HBase-1.1.10RC0) is available for download at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.10RC0/
>
> Maven artifacts are also available in the staging repository
> https://repository.apache.org/content/repositories/orgapachehbase-1167
>
> Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
> available in the Apache keys directory https://people.apache.org/
> keys/committer/ndimiduk.asc and in our KEYS file
> http://www-us.apache.org/dist/hbase/KEYS.
>
> Please note that this signing key is set to expire at the end of this
> month. I will be taking steps to extend its expiration date. This should be
> transparent, but may cause some hiccups.
>
> There's also a signed tag for this release at
> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=
> 4a7f2062f5776d6423d19f6d88bc4161c33ccd0c
>
> The detailed source and binary compatibility report vs 1.1.9 has been
> published for your review, at https://home.apache.org/~
> ndimiduk/1.1.9_1.1.10RC0_compat_report.html
>
> HBase 1.1.10 is the tenth patch release in the HBase 1.1 line, continuing
> on the theme of bringing a stable, reliable database to the Hadoop and
> NoSQL communities. This release includes over 10 bug fixes since the 1.1.9
> release. Notable correctness fixes include HBASE-17675, HBASE-17682,
> HBASE-17287, and HBASE-17717.
>
> The full list of fixes included in this release is available at
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12310753&version=12339651 and and in the CHANGES.txt file
> included in the distribution.
>
> Please try out this candidate and vote +/-1 by 23:59 Pacific time on
> Tuesday, 2017-04-24 as to whether we should release these artifacts as
> HBase 1.1.10.
>
> Thanks,
> Nick
>

Re: [VOTE] First release candidate for HBase 1.1.10 (RC0) is available

[Nick Dimiduk]

On Tue, Apr 18, 2017 at 10:00 PM, Nick Dimiduk  wrote:

>
> Please try out this candidate and vote +/-1 by 23:59 Pacific time on
> Tuesday, 2017-04-24 as to whether we should release these artifacts as
> HBase 1.1.10.
>

I botched my dates and days. Will leave this open through tomorrow 23:59
Pacific,  Tuesday, 2017-04-25.

Re: [DISCUSS] More Shading

[Nick Dimiduk]

FYI, MNG-5899 makes shaded builds fragile, effectively limiting
multi-module shaded projects to maven 3.2.x. Apparently the Apache Storm
folks tripped over this earlier, and as I recall, Apache Flink used to
require building with 3.2.x for the same reason.

https://issues.apache.org/jira/browse/MNG-5899

On Tue, Apr 18, 2017 at 9:20 PM, Nick Dimiduk  wrote:

> On Wed, Apr 12, 2017 at 2:30 PM, Stack  wrote:
>
>> > >> If the above quote is true, then I think what we want is a set of
>> > shaded
>> > > >> Hadoop client libs that we can depend on so as to not get all the
>> > > >> transitive deps. Hadoop doesn't provide it, but we could do so
>> > ourselves
>> > > >> with (yet another) module in our project. Assuming, that is, the
>> > > upstream
>> > > >> client interfaces are well defined and don't leak stuff we care
>> about.
>> >
>>
>>
>> We should do this too (I think you've identified the big 'if' w/ the above
>> identified assumption). As you say later, "... it's time we firm up the
>> boundaries between us and Hadoop.". There is some precedent with
>> hadoop-compat-* modules. Hadoop would be relocated?
>>
>
> Ideally we'd relocate any parts of Hadoop that are not part of our public
> contract. Not sure if there's an intersection between "ideal" and
> "practical" though.
>
> Spitballing, IIUC, I think this would be a big job (once per version and
>> the vagaries of hadoop/spark) with no guarantee of success on other end
>> because of assumption you call out. Do I have this right?
>>
>
> Yeah you have my meaning. My argument is not whether we should shade but
> rather how we make it a maintainable deployment tool for our team of
> volunteers. Hence interest in compatibility verification tools like we do
> with our api compatibility tools.
>
> > Isolating our clients from our deps is best served by our shaded modules.
>> > What do you think about turning things on their head: for 2.0 the
>> > hbase-client jar is the shaded artifact by default, not the other way
>> > around? We have cleanup to get our deps out of our public interfaces in
>> > order to make this work.
>> >
>> >
>> We should do this at least going forward. hbase2 is the opportunity.
>> Testing and doc is all that is needed? I added it to our hbase2
>> description
>> doc as a deliverable (though not a blocker).
>>
>
> I've not tried to consume these efforts. A reasonable test-case to see if
> these are ready for prime-time would be to try rebuilding one of the more
> complex downstream projects (i.e, Phoenix, Trafodion, Splice) using the
> shaded jars and see how bad the diff is.
>
> > This proposal of an external shaded dependencies module sounds like an
>> > attempt to solve both concerns at once. It would isolate ourselves from
>> > Hadoop's deps, and it would isolate our clients from our deps. However,
>> it
>> > doesn't isolate our clients from Hadoop's deps, so our users don't
>> really
>> > gain anything from it. I also argue that it creates an unreasonable
>> release
>> > engineering burden on our project. I'm also not clear on the
>> implications
>> > to downstreamers who extend us with coprocessors.
>> >
>>
>>
>> Other than a missing 'quick-fix' descriptor, you call what is proposed
>> well
>> except where you think the prebuild will be burdensome. Here I think
>> otherwise as I think releases will be rare, there is nought 'new' in a
>> release but packaged 3rd-party libs, and verification/vote by PMCers
>> should
>> be a simple affair.
>>
>
> Maybe it's not such a burden? If the 2.0 and 3.0 RM's are brave and true,
> it's worth a go.
>
> Do you agree that the fixing-what-we-leak-of-hadoop-to-downstreamers is
>> distinct from the narrower task proposed here where we are trying to
>> unhitch ourselves of the netty/guava hadoop uses? (Currently we break
>> against hadoop3 because of netty incompat., HADOOP-13866, which we might
>> be
>> able to solve w/ exclusions.but).
>>
>> The two tasks can be run in parallel?
>>
>
> Indeed, they seem distinct but quite related.
>
> For CPs, they should bring their own bedding and towels and not be trying
>> to use ours. On the plus-side, we could upgrade core 3rd-party libs and
>> the
>> CP would keep working.
>>
>
> All of this sounds like an ideal state.
>

[RESULT][VOTE] First release candidate for HBase 1.1.10 (RC0) is available

[Nick Dimiduk]

This measure PASSES with votes 5 +1 and no other votes cast. Thanks to all
who took the time. I will promotes these bits as 1.1.10.

-n

On Tue, Apr 18, 2017 at 10:00 PM, Nick Dimiduk  wrote:

> I'm happy to announce the first release candidate of HBase 1.1.10
> (HBase-1.1.10RC0) is available for download at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.10RC0/
>
> Maven artifacts are also available in the staging repository
> https://repository.apache.org/content/repositories/orgapachehbase-1167
>
> Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
> available in the Apache keys directory https://people.apache.org/
> keys/committer/ndimiduk.asc and in our KEYS file
> http://www-us.apache.org/dist/hbase/KEYS.
>
> Please note that this signing key is set to expire at the end of this
> month. I will be taking steps to extend its expiration date. This should be
> transparent, but may cause some hiccups.
>
> There's also a signed tag for this release at
> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=
> 4a7f2062f5776d6423d19f6d88bc4161c33ccd0c
>
> The detailed source and binary compatibility report vs 1.1.9 has been
> published for your review, at https://home.apache.org/~
> ndimiduk/1.1.9_1.1.10RC0_compat_report.html
>
> HBase 1.1.10 is the tenth patch release in the HBase 1.1 line, continuing
> on the theme of bringing a stable, reliable database to the Hadoop and
> NoSQL communities. This release includes over 10 bug fixes since the 1.1.9
> release. Notable correctness fixes include HBASE-17675, HBASE-17682,
> HBASE-17287, and HBASE-17717.
>
> The full list of fixes included in this release is available at
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12310753&version=12339651 and and in the CHANGES.txt file
> included in the distribution.
>
> Please try out this candidate and vote +/-1 by 23:59 Pacific time on
> Tuesday, 2017-04-24 as to whether we should release these artifacts as
> HBase 1.1.10.
>
> Thanks,
> Nick
>

Re: [VOTE] First release candidate for HBase 1.1.10 (RC0) is available

[Nick Dimiduk]

On Wed, Apr 19, 2017 at 12:48 PM, Josh Elser  wrote:

> * NOTICE file needs an update (copyright year). The notes about "Licensed
> under Apache License, version 2.0" also appear unnecessary to me (but are
> only "bad" in that it unnecessarily bloats our NOTICE).
>

I've opened a ticket so we won't lose track of the copyright year:
https://issues.apache.org/jira/browse/HBASE-17968

Nick Dimiduk wrote:
>
>> I'm happy to announce the first release candidate of HBase 1.1.10
>> (HBase-1.1.10RC0) is available for download at
>> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.10RC0/
>>
>> Maven artifacts are also available in the staging repository
>> https://repository.apache.org/content/repositories/orgapachehbase-1167
>>
>> Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
>> available in the Apache keys directory
>> https://people.apache.org/keys/committer/ndimiduk.asc and in our KEYS
>> file
>> http://www-us.apache.org/dist/hbase/KEYS.
>>
>> Please note that this signing key is set to expire at the end of this
>> month. I will be taking steps to extend its expiration date. This should
>> be
>> transparent, but may cause some hiccups.
>>
>> There's also a signed tag for this release at
>> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=
>> 4a7f2062f5776d6423d19f6d88bc4161c33ccd0c
>>
>> The detailed source and binary compatibility report vs 1.1.9 has been
>> published for your review, at
>> https://home.apache.org/~ndimiduk/1.1.9_1.1.10RC0_compat_report.html
>>
>> HBase 1.1.10 is the tenth patch release in the HBase 1.1 line, continuing
>> on the theme of bringing a stable, reliable database to the Hadoop and
>> NoSQL communities. This release includes over 10 bug fixes since the 1.1.9
>> release. Notable correctness fixes include HBASE-17675, HBASE-17682,
>> HBASE-17287, and HBASE-17717.
>>
>> The full list of fixes included in this release is available at
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>> ctId=12310753&version=12339651
>> and and in the CHANGES.txt file included in the distribution.
>>
>> Please try out this candidate and vote +/-1 by 23:59 Pacific time on
>> Tuesday, 2017-04-24 as to whether we should release these artifacts as
>> HBase 1.1.10.
>>
>> Thanks,
>> Nick
>>
>>

[ANNOUNCE] Apache HBase 1.1.10 is now available for download

[Nick Dimiduk]

The HBase team is happy to announce the immediate availability of HBase
1.1.10! Download it from an Apache mirror near you,
http://www.apache.org/dyn/closer.lua/hbase/, or wire up through the maven
repo.

Apache HBase is an open-source, distributed, versioned, non-relational
database. Apache HBase gives you low latency random access to billions of
rows with millions of columns atop non-specialized hardware. To learn more
about HBase, see https://hbase.apache.org/.

HBase 1.1.10 is the tenth patch release in the HBase 1.1 line, continuing
on the theme of bringing a stable, reliable database to the Hadoop and
NoSQL communities. This release includes over 10 bug fixes since the 1.1.9
release. Notable correctness fixes include:

HBASE-17287 Master becomes a zombie if filesystem object closes
HBASE-17675 ReplicationEndpoint should choose new sinks if a SaslException
occurs
HBASE-17682 Region stuck in merging_new state indefinitely
HBASE-17717 Incorrect ZK ACL set for HBase superuser

The full list of fixes included in this release is available at
https://issues.apache.org/jira/secure/ReleaseNote.jspa?
projectId=12310753&version=12339651 and in the CHANGES.txt file included in
the distribution.

Question, comments, and problems are always welcome at: dev@hbase.apache.org
.

Thanks to all the contributors who made this release possible!

Cheers,
The HBase Dev Team

Time to retire EOM branch releases from dist?

[Nick Dimiduk]

Heya,

I noticed we still have hbase-0.94.27 and hbase-1.0.3 syncing out on the
mirrors [0]. Since both of these lines are formally EOM, I think it's time
to retire the bits as well. Of course, people can always grab them from the
Apache Archives [1]. If there's no objections, I'll take rm them this week.

Thanks,
Nick

[0]: https://www-us.apache.org/dist/hbase/
[1]: https://archive.apache.org/dist/hbase/

Re: Time to retire EOM branch releases from dist?

[Nick Dimiduk]

While I'm in there, I'll drop 1.3.0 as well? Should be only one release per
branch, IIRC.

On Sun, Apr 30, 2017 at 8:30 PM Mikhail Antonov 
wrote:

> +1, and also to EOM 0.98.
>
> On Sun, Apr 30, 2017 at 6:35 PM, Andrew Purtell 
> wrote:
>
> > We also have decided 0.98 is EOM too, I believe.
> >
> >
> > > On Apr 30, 2017, at 5:29 PM, Nick Dimiduk  wrote:
> > >
> > > Heya,
> > >
> > > I noticed we still have hbase-0.94.27 and hbase-1.0.3 syncing out on
> the
> > > mirrors [0]. Since both of these lines are formally EOM, I think it's
> > time
> > > to retire the bits as well. Of course, people can always grab them from
> > the
> > > Apache Archives [1]. If there's no objections, I'll take rm them this
> > week.
> > >
> > > Thanks,
> > > Nick
> > >
> > > [0]: https://www-us.apache.org/dist/hbase/
> > > [1]: https://archive.apache.org/dist/hbase/
> >
>
>
>
> --
> Thanks,
> Michael Antonov
>

Re: Time to retire EOM branch releases from dist?

[Nick Dimiduk]

My mistake; I was somehow looking at a stale view of that directory. All is
well. I'll let Mikhail take care of the 1.3.x stuff.

On Mon, May 1, 2017 at 1:31 PM, Enis Söztutar  wrote:

> https://dist.apache.org/repos/dist/release/hbase/
>
> Does not have EOM'ed ones. But to answer Mikhail's question, yes if a new
> "patch" release comes out, the old patch version should be moved (so that
> users are encouraged to use the new one). Should be part of the release
> documentation already I believe. If not we can add it there. Let's remove
> 1.3.0 from there.
>
>
> Enis
>
> On Mon, May 1, 2017 at 12:24 PM, Sean Busbey  wrote:
>
> > I thought I had already cleaned up 0.94, 0.98, and 1.0 releases from
> > dist back in HBASE-16215. Where are you still seeing them?
> >
> >
> >
> >
> > On Sun, Apr 30, 2017 at 7:29 PM, Nick Dimiduk 
> wrote:
> > > Heya,
> > >
> > > I noticed we still have hbase-0.94.27 and hbase-1.0.3 syncing out on
> the
> > > mirrors [0]. Since both of these lines are formally EOM, I think it's
> > time
> > > to retire the bits as well. Of course, people can always grab them from
> > the
> > > Apache Archives [1]. If there's no objections, I'll take rm them this
> > week.
> > >
> > > Thanks,
> > > Nick
> > >
> > > [0]: https://www-us.apache.org/dist/hbase/
> > > [1]: https://archive.apache.org/dist/hbase/
> >
>

Time for 1.1.11

[Nick Dimiduk]

Hello!

Is time to be considering another release from branch-1.1. Just like last
time, there's very few commits since the last release tag. However, this
time we have a couple nice ones.

I have a busy week this week, but I'm planning to squeeze release-making in
there before Friday. Please push ahead on anything you've got pending, let
me know if you need an extra day or two.

Thanks,
Nick

Re: [RESULT] Re: [VOTE] First release candidate for HBase 1.2.6 is available

[Nick Dimiduk]

Nice turn-out everyone!

On Fri, Jun 2, 2017 at 8:32 PM Sean Busbey  wrote:

> With five binding +1s and one non-binding +1, this vote passes.
>
> Thanks folks!
>
>
>
> On Mon, May 29, 2017 at 11:31 AM, Sean Busbey  wrote:
> > The first release candidate for HBase 1.2.6 is available for download at:
> >
> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.6RC0/
> >
> > Maven artifacts are also available in a staging repository at:
> >
> > https://repository.apache.org/content/repositories/orgapachehbase-1168/
> >
> > Artifacts are signed with my key (0D80DB7C) published in our KEYS
> > file at http://www.apache.org/dist/hbase/KEYS
> >
> > The RC corresponds to the signed tag 1.2.6RC0, which currently points
> > to commit ref
> >
> > 2f9b9e17d0522e36063bf52ecc58576243d20b3f
> >
> > The detailed source and binary compatibility report vs 1.2.5 has been
> > published for your review, at:
> >
> > https://s.apache.org/hbase-1.2.6-rc0-compat-report
> >
> > HBase 1.2.6 is the sixth maintenance release in the HBase 1.2 line,
> > continuing on the theme of bringing a stable, reliable database to
> > the Hadoop and NoSQL communities. This release includes over 25
> > bug fixes since 1.2.5.
> >
> > Critical fixes include:
> >
> > * HBASE-17287 - Master becomes a zombie if filesystem object closes
> > * HBASE-16630 - Fragmentation in long running Bucket Cache
> > * HBASE-17717 - Incorrect ZK ACL set for HBase superuser
> > * HBASE-15941 - HBCK repair should not unsplit healthy splitted region
> >
> > The full list of fixes included in this release is available at:
> >
> > https://s.apache.org/hbase-1.2.6-jira-release-notes
> >
> > and in the CHANGES.txt file included in the distribution.
> >
> > Please try out this candidate and vote +1/-1 on whether we should
> > release these artifacts as HBase 1.2.6.
> >
> > The VOTE will remain open for at least 72 hours. Given sufficient votes
> > I would like to close it on June 5th, 2017.
> >
> > thanks!
>

[VOTE] First release candidate for HBase 1.1.11 (RC0) is available

[Nick Dimiduk]

I'm happy to announce the first release candidate of HBase 1.1.11
(HBase-1.1.11RC0) is available for download at
https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.11RC0/

Maven artifacts are also available in the staging repository
https://repository.apache.org/content/repositories/orgapachehbase-1170/

Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
available in the Apache keys directory
https://people.apache.org/keys/committer/ndimiduk.asc and in our KEYS file
http://www-us.apache.org/dist/hbase/KEYS.

There's also a signed tag for this release at
https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=d318fbeef0990e53efb313c1a459cce73ed4edb8

The detailed source and binary compatibility report vs 1.1.10 has been
published for your review, at
https://home.apache.org/~ndimiduk/1.1.10_1.1.11RC0_compat_report.html

HBase 1.1.11 is the eleventh patch release in the HBase 1.1 line,
continuing on the theme of bringing a stable, reliable database to the
Hadoop and NoSQL communities. This release includes nearly 20 bug fixes
since the 1.1.10 release. Notable correctness fixes include
HBASE-17937, HBASE-18036, HBASE-18081, HBASE-18093, HBASE-16011, and
HBASE-18066.

The full list of fixes included in this release is available at
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310753&version=12340375
and and in the CHANGES.txt file included in the distribution.

Let's leave this vote up an extra couple days since HBaseCon is this week.
Please try out this candidate and vote +/-1 by 23:59 Pacific time on
Sunday, 2017-06-18 as to whether we should release these artifacts as HBase
1.1.11.

Thanks,
Nick

Re: [VOTE] First release candidate for HBase 1.1.11 (RC0) is available

[Nick Dimiduk]

+1

- verified tarballs vs public key on people.apache.org.
- extracted bin tgz:
  - inspect structure. look good.
  - with jdk1.8.0_65:
- run LoadTestTool against standalone bin tgz with FAST_DIFF block
encoder and ROWCOL blooms. No issues, logs look good.
- poked around webUI. looks good.
  - load the site, browsed book.
- extracted src tgz:
  - inspect structure. look good.
  - run LoadTestTool against standalone built from src tgz with FAST_DIFF
block encoder and ROWCOL blooms. No issues, logs look good.
  - poked around webUI. looks good.
- ran the hbase-downstreamer project vs. the staged maven repository. tests
pass.

On Sat, Jun 10, 2017 at 7:40 PM, Nick Dimiduk  wrote:

> I'm happy to announce the first release candidate of HBase 1.1.11
> (HBase-1.1.11RC0) is available for download at https://dist.apache.org/
> repos/dist/dev/hbase/hbase-1.1.11RC0/
>
> Maven artifacts are also available in the staging repository
> https://repository.apache.org/content/repositories/orgapachehbase-1170/
>
> Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
> available in the Apache keys directory https://people.apache.org/
> keys/committer/ndimiduk.asc and in our KEYS file
> http://www-us.apache.org/dist/hbase/KEYS.
>
> There's also a signed tag for this release at
> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=
> d318fbeef0990e53efb313c1a459cce73ed4edb8
>
> The detailed source and binary compatibility report vs 1.1.10 has been
> published for your review, at https://home.apache.org/~
> ndimiduk/1.1.10_1.1.11RC0_compat_report.html
>
> HBase 1.1.11 is the eleventh patch release in the HBase 1.1 line,
> continuing on the theme of bringing a stable, reliable database to the
> Hadoop and NoSQL communities. This release includes nearly 20 bug fixes
> since the 1.1.10 release. Notable correctness fixes include
> HBASE-17937, HBASE-18036, HBASE-18081, HBASE-18093, HBASE-16011, and
> HBASE-18066.
>
> The full list of fixes included in this release is available at
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12310753&version=12340375 and and in the CHANGES.txt file
> included in the distribution.
>
> Let's leave this vote up an extra couple days since HBaseCon is this week.
> Please try out this candidate and vote +/-1 by 23:59 Pacific time on
> Sunday, 2017-06-18 as to whether we should release these artifacts as HBase
> 1.1.11.
>
> Thanks,
> Nick
>

[RESULT][VOTE] First release candidate for HBase 1.1.11 (RC0) is available

[Nick Dimiduk]

With 5 binding votes cast +1 and no other votes recorded, this measure
passes. I will promote RC0 as 1.1.11.

Thanks to everyone who took the time.
-n

On Mon, Jun 19, 2017 at 4:38 AM, Anoop John  wrote:

> +1
>
> Signature ok
> Built from src and looks good
> UT pass
> Started a single node cluster and run some commands from shell. Looks ok
>
> Loaded  1GB data and some random reads . Looks ok
>
> -Anoop-
>
>
> On Fri, Jun 16, 2017 at 7:34 AM, Yu Li  wrote:
> > +1
> >
> > Checked sums and signatures: ok
> > Built from source: ok (7u79)
> > RAT check: ok (7u79)
> > Compatibility check: ok (7u79), ran check_compatibility.sh locally, 100%
> > compatible with 1.1.10 (both binary and source)
> > Unit tests pass: ok (8u101)
> > - Passed with -Dsurefire.rerunFailingTestsCount=2
> > Shell commands: ok (8u101), ran DDL/flush/compact/split commands,
> > everything looks good
> > Loaded 1M rows with LTT: ok (8u101), all keys verified, latency and logs
> > looks good
> >
> > Best Regards,
> > Yu
> >
> > On 16 June 2017 at 01:35, Josh Elser  wrote:
> >
> >> +1 (binding)
> >>
> >> * No unexpected binaries in source release
> >> * L&N look good
> >> * Could build from source
> >> * Could run bin-tarball as-is
> >> * Checked compat report (thanks for publishing)
> >> * xsum/sigs OK
> >> * Ran a PE randomwritetest
> >>
> >>
> >> On 6/10/17 7:40 PM, Nick Dimiduk wrote:
> >>
> >>> I'm happy to announce the first release candidate of HBase 1.1.11
> >>> (HBase-1.1.11RC0) is available for download at
> >>> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.11RC0/
> >>>
> >>> Maven artifacts are also available in the staging repository
> >>> https://repository.apache.org/content/repositories/
> orgapachehbase-1170/
> >>>
> >>> Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
> >>> available in the Apache keys directory
> >>> https://people.apache.org/keys/committer/ndimiduk.asc and in our KEYS
> >>> file
> >>> http://www-us.apache.org/dist/hbase/KEYS.
> >>>
> >>> There's also a signed tag for this release at
> >>> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=
> >>> d318fbeef0990e53efb313c1a459cce73ed4edb8
> >>>
> >>> The detailed source and binary compatibility report vs 1.1.10 has been
> >>> published for your review, at
> >>> https://home.apache.org/~ndimiduk/1.1.10_1.1.11RC0_compat_report.html
> >>>
> >>> HBase 1.1.11 is the eleventh patch release in the HBase 1.1 line,
> >>> continuing on the theme of bringing a stable, reliable database to the
> >>> Hadoop and NoSQL communities. This release includes nearly 20 bug fixes
> >>> since the 1.1.10 release. Notable correctness fixes include
> >>> HBASE-17937, HBASE-18036, HBASE-18081, HBASE-18093, HBASE-16011, and
> >>> HBASE-18066.
> >>>
> >>> The full list of fixes included in this release is available at
> >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> >>> ctId=12310753&version=12340375
> >>> and and in the CHANGES.txt file included in the distribution.
> >>>
> >>> Let's leave this vote up an extra couple days since HBaseCon is this
> week.
> >>> Please try out this candidate and vote +/-1 by 23:59 Pacific time on
> >>> Sunday, 2017-06-18 as to whether we should release these artifacts as
> >>> HBase
> >>> 1.1.11.
> >>>
> >>> Thanks,
> >>> Nick
> >>>
> >>>
>

[ANNOUNCE] Apache HBase 1.1.11 is now available for download

[Nick Dimiduk]

The HBase team is happy to announce the immediate availability of HBase
1.1.11! Download it from an Apache mirror near you,
http://www.apache.org/dyn/closer.lua/hbase/, or wire up through the maven
repo.

Apache HBase is an open-source, distributed, versioned, non-relational
database. Apache HBase gives you low latency random access to billions of
rows with millions of columns atop non-specialized hardware. To learn more
about HBase, see https://hbase.apache.org/.

HBase 1.1.11 is the eleventh patch release in the HBase 1.1 line,
continuing on the theme of bringing a stable, reliable database to the
Hadoop and NoSQL communities. This release includes nearly 20 bug fixes
since the 1.1.10 release. Notable correctness fixes include

HBASE-16011 TableSnapshotScanner and TableSnapshotInputFormat can produce
duplicate rows
HBASE-17937 Memstore size becomes negative in case of expensive
postPut/Delete Coprocessor call
HBASE-18036 HBase 1.x : Data locality is not maintained after cluster
restart or SSH
HBASE-18066 Get with closest_row_before on "hbase:meta" can return empty
Cell during region merge/split
HBASE-18081 The way we process connection preamble in SimpleRpcServer is
broken
HBASE-18093 Overloading the meaning of 'enabled' in Quota Manager to
indicate either quota disabled or quota manager not ready is not good

The full list of fixes included in this release is available at
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310753&version=12340375
and and in the CHANGES.txt file included in the distribution.

Question, comments, and problems are always welcome at: dev@hbase.apache.org
.

Thanks to all the contributors who made this release possible!

Cheers,
The HBase Dev Team

Re: [ANNOUNCE] Devaraj Das joins the Apache HBase PMC

[Nick Dimiduk]

Congratulations Devaraj!

On Wed, Jul 5, 2017 at 9:27 AM, Josh Elser  wrote:

> I'm pleased to announce yet another PMC addition in the form of Devaraj
> Das. One of the "old guard" in the broader Hadoop umbrella, he's also a
> long-standing member in our community. We all look forward to the continued
> contributions and project leadership.
>
> Please join me in welcoming Devaraj!
>
> - Josh (on behalf of the PMC)
>

About time for HBase 1.1.12

[Nick Dimiduk]

Hello,

It's been over a month since the last maintenance release. We have more
than 10 commits to branch-1.1. Thus I think it's time to spin a new RC.
I'll be doing my JIRA pruning in the coming days. Please land any commits
you feel are ready. Let's aim to start the VOTE early next week.

Thanks,
Nick

Re: DISCUSS: How can we have less branches?

[Nick Dimiduk]

Last time we DISCUSSed EOL of 1.1 was back in November. At that time, a
litany of issues were raised re: 1.2. Have those concerns been addressed?
It seems to me that making this one the last release is too abrupt to folks
tracking Apache. Would be better to give some notice.

Had a nice hallway conversation a couple months back (at PhoenixCon, as it
happens; they feel the pain as well) about our branch situation. I'll let
the others chime in with more details, but the gist as I recall is that we
should be doing more frequent minor releases with fewer patch releases.
This pushes stabilization efforts closer to master and also imposes more
strict stability requirements on big new features before they can be merged
off the feature branch.

The discussion also brought up the notion of an LTS release line. I'm not
sure how this jives with the more fequent minors, but would require some
branch that's so stable that an RM can effectively spin releases blind.

On Tue, Aug 8, 2017 at 12:14 AM Stack  wrote:

> (This came up during dev meeting in Shenzhen) We are running too many
> branches and/or when applying patches, we do not do a good job backporting
> to all active branches, especially fixes.
>
> We have master, branch-2, branch-1, branch-1.4, branch-1.3, branch-1.2, and
> branch-1.1 active currently. If a dirty bug fix, the applier is backporting
> to 7 branches. It takes a while applying to all especially if the backport
> doesn't go in clean. I suppose the RM could monitor all upstream of them
> and then pull wanted patches back (we could do that too) but seems like a
> burden on an RMer.
>
> We should EOL a few?
>
> Nick is on branch-1.1 release at the moment. Perhaps this could be the last
> off branch-1.1.
>
> 1.2 hosts our current stable release though 1.3 is out. How about we cut a
> release off 1.3, call it stable, and then EOL 1.2 after another release or
> so?
>
> What you all think?
>
> Thanks,
> S
>

Re: DISCUSS: How can we have less branches?

[Nick Dimiduk]

On Tue, Aug 8, 2017 at 9:15 AM Mike Drob  wrote:

> > The discussion also brought up the notion of an LTS release line. I'm not
> > sure how this jives with the more fequent minors, but would require some
> > branch that's so stable that an RM can effectively spin releases blind.
>
> Seems to me like this branch would necessarily need to be very
> backport-light? Only the top of the highest priority issues would be
> backportable to it, no?


The LTS is as 1.1 is today -- bug fixes only. The difference here is we'd
"formally" recognize the LTS designation somehow, perhaps with a symlink
marker as we do for the "stable" designation.

On Tue, Aug 8, 2017 at 11:09 AM, Nick Dimiduk  wrote:
>
> > Last time we DISCUSSed EOL of 1.1 was back in November. At that time, a
> > litany of issues were raised re: 1.2. Have those concerns been addressed?
> > It seems to me that making this one the last release is too abrupt to
> folks
> > tracking Apache. Would be better to give some notice.
> >
> > Had a nice hallway conversation a couple months back (at PhoenixCon, as
> it
> > happens; they feel the pain as well) about our branch situation. I'll let
> > the others chime in with more details, but the gist as I recall is that
> we
> > should be doing more frequent minor releases with fewer patch releases.
> > This pushes stabilization efforts closer to master and also imposes more
> > strict stability requirements on big new features before they can be
> merged
> > off the feature branch.
> >
> > The discussion also brought up the notion of an LTS release line. I'm not
> > sure how this jives with the more fequent minors, but would require some
> > branch that's so stable that an RM can effectively spin releases blind.
> >
> > On Tue, Aug 8, 2017 at 12:14 AM Stack  wrote:
> >
> > > (This came up during dev meeting in Shenzhen) We are running too many
> > > branches and/or when applying patches, we do not do a good job
> > backporting
> > > to all active branches, especially fixes.
> > >
> > > We have master, branch-2, branch-1, branch-1.4, branch-1.3, branch-1.2,
> > and
> > > branch-1.1 active currently. If a dirty bug fix, the applier is
> > backporting
> > > to 7 branches. It takes a while applying to all especially if the
> > backport
> > > doesn't go in clean. I suppose the RM could monitor all upstream of
> them
> > > and then pull wanted patches back (we could do that too) but seems
> like a
> > > burden on an RMer.
> > >
> > > We should EOL a few?
> > >
> > > Nick is on branch-1.1 release at the moment. Perhaps this could be the
> > last
> > > off branch-1.1.
> > >
> > > 1.2 hosts our current stable release though 1.3 is out. How about we
> cut
> > a
> > > release off 1.3, call it stable, and then EOL 1.2 after another release
> > or
> > > so?
> > >
> > > What you all think?
> > >
> > > Thanks,
> > > S
> > >
> >
>

[VOTE] First release candidate for HBase 1.1.12 (RC0) is available

[Nick Dimiduk]

I'm happy to announce the first release candidate of HBase 1.1.12
(HBase-1.1.12RC0) is available for download at https://dist.apache.org/
repos/dist/dev/hbase/hbase-1.1.12RC0/

Maven artifacts are also available in the staging repository
https://repository.apache.org/content/repositories/orgapachehbase-1172

Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
available in the Apache keys directory https://people.apache.org/
keys/committer/ndimiduk.asc and in our KEYS file
http://www-us.apache.org/dist/hbase/KEYS.

There's also a signed tag for this release at https://git-wip-us.apache.org/
repos/asf?p=hbase.git;a=tag;h=29a930cdcbef2a64b601a110bad72955b3b04afc

The detailed source and binary compatibility report vs 1.1.9 has been
published for your review, at https://home.apache.org/~
ndimiduk/1.1.11_1.1.12RC0_compat_report.html

HBase 1.1.12 is the twelfth patch release in the HBase 1.1 line, continuing
on the theme of bringing a stable, reliable database to the Hadoop and
NoSQL communities. This release includes nearly 10 bug fixes since the
1.1.11 release. Notable correctness fixes include HBASE-9393,
HBASE-15691, HBASE-18390,
HBASE-18330.

The full list of fixes included in this release is available at
https://issues.apache.org/jira/secure/ReleaseNote.jspa?
projectId=12310753&version=12340864 and and in the CHANGES.txt file
included in the distribution.

Please try out this candidate and vote +/-1 by 23:59 Pacific time on
Saturday, 2017-08-19 as to whether we should release these artifacts as
HBase 1.1.12.

Thanks,
Nick

Re: [VOTE] First release candidate for HBase 1.1.12 (RC0) is available

[Nick Dimiduk]

+1

- verified tarballs vs public key on people.apache.org.
- extracted bin tgz:
  - inspect structure. look good.
  - with jdk1.8.0_65:
- run LoadTestTool against standalone bin tgz with FAST_DIFF block
encoder and ROWCOL blooms. No issues, logs look good.
- poked around webUI. looks good.
  - load the site, browsed book.
- extracted src tgz:
  - inspect structure. look good.
  - run LoadTestTool against standalone built from src tgz with FAST_DIFF
block encoder and ROWCOL blooms. No issues, logs look good.
  - poked around webUI. looks good.
- ran the hbase-downstreamer project vs. the staged maven repository. tests
pass.

On Sat, Aug 12, 2017 at 3:09 PM, Nick Dimiduk  wrote:

> I'm happy to announce the first release candidate of HBase 1.1.12
> (HBase-1.1.12RC0) is available for download at https://dist.apache.org/rep
> os/dist/dev/hbase/hbase-1.1.12RC0/
>
> Maven artifacts are also available in the staging repository
> https://repository.apache.org/content/repositories/orgapachehbase-1172
>
> Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
> available in the Apache keys directory https://people.apache.org/keys
> /committer/ndimiduk.asc and in our KEYS file
> http://www-us.apache.org/dist/hbase/KEYS.
>
> There's also a signed tag for this release at
> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=
> 29a930cdcbef2a64b601a110bad72955b3b04afc
>
> The detailed source and binary compatibility report vs 1.1.9 has been
> published for your review, at https://home.apache.org/~ndimi
> duk/1.1.11_1.1.12RC0_compat_report.html
>
> HBase 1.1.12 is the twelfth patch release in the HBase 1.1 line,
> continuing on the theme of bringing a stable, reliable database to the
> Hadoop and NoSQL communities. This release includes nearly 10 bug fixes
> since the 1.1.11 release. Notable correctness fixes include
> HBASE-9393, HBASE-15691, HBASE-18390, HBASE-18330.
>
> The full list of fixes included in this release is available at
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> ctId=12310753&version=12340864 and and in the CHANGES.txt file included
> in the distribution.
>
> Please try out this candidate and vote +/-1 by 23:59 Pacific time on
> Saturday, 2017-08-19 as to whether we should release these artifacts as
> HBase 1.1.12.
>
> Thanks,
> Nick
>

Re: [VOTE] First release candidate for HBase 1.1.12 (RC0) is available

[Nick Dimiduk]

On Sat, Aug 12, 2017 at 3:09 PM, Nick Dimiduk  wrote:

> The detailed source and binary compatibility report vs 1.1.9 has been
> published for your review, at https://home.apache.org/~ndimi
> duk/1.1.11_1.1.12RC0_compat_report.html
>

Apologies; that's a report vs. 1.1.11.

Re: [DISCUSS] Remove HTrace 3.2.0-incubating from HBase

[Nick Dimiduk]

IMHO, we should be actively pruning half-implemented, testless, ownerless
code. HTrace queues up well for that chopping block. Long back I wanted to
see this particular feature though, but I cannot volunteer for the role
currently. If Phoenix devs are advertising this feature to their users,
their contributions re: HBase and HDFS maintenance would be well received.

I question the choice of HTrace as the tool for the job, given the relative
lack of activity in that project vs. the myriad alternatives out there.
HTrace has been incubating for 2.5 years, has seen only 5 releases, with no
release in the last 18 months. I haven't evaluated the field in a while,
but there's probably something with much more mature tooling and support.
For instance, openzipkin/brave has much more activity more recently.

-n

On Tue, Aug 15, 2017 at 2:28 PM Stack  wrote:

> On Tue, Aug 15, 2017 at 12:38 PM, Andrew Purtell 
> wrote:
>
> > Doc update to indicate HTrace is unfinished is fine.
> >
> >
> We could do this. Update jar and doc it as broke.
>
>
>
> > Phoenix uses HTrace to support query tracing. It "works".
>
>
> Nit: I didn't think this was htrace. It was an old version pulled into
> phoenix world where it lives storing to phoenix table reporting on
> phoenix-only spans.
>
>
>
> > A colleague made
> > a contribution to HDFS to fix a case where spans could get muddied around
> > the WAL. We are carrying that patch on top of 2.7 for the moment but IIRC
> > it's in 2.8.
> >
> > Removing all of our HBase level spans doesn't make sense to me when spans
> > at HDFS level will not be removed, nor at the Phoenix level.
>
>
> The spans in hbase are just hanging until they get the htrace-4 revamp and
> the dots get connected.
>
>
>
> > We hollow out
> > the middle. I think this is worse than leaving things at a half finished
> > state. At least in the half finished state it might get finished.
> >
> >
> Nod.
>
>
>
> > What are the most pressing issues? I'm up for supporting an "HTrace" get
> > well. I'll need your (community) help for getting patches into Hadoop if
> > need be.
> >
> >
> HTrace needs care and a viewer (zipkin I think now it has come back alive).
>
> HBase needs a couple of narratives wired through.
>
> Ditto HDFS.
>
> St.Ack
>
>
>
> >
> > On Tue, Aug 15, 2017 at 12:10 PM, Stack  wrote:
> >
> > > On Tue, Aug 15, 2017 at 11:22 AM, Andrew Purtell 
> > > wrote:
> > >
> > > > -1 to removing HTrace from HBase.
> > > >
> > > > Upgrade to the desired version, that would be fine.
> > > >
> > > >
> > > ​t​
> > >
> > > What you thinking Andrew?
> > >
> > > Trace is broke whether we upgrade or not. As is, we mislead. We give
> off
> > > the impression that hooking up hbase and hdfs via trace tells a story
> > about
> > > request traversals when it at best you'd get a wonky view.
> > >
> > > HTrace needs work. HBase and HDFS also need work before we can suggest
> to
> > > our users this system is viable debugging.
> > >
> > > What you reckon Andrew?
> > > Thanks,
> > > S
> > >
> > >
> > >
> > >
> > > >
> > > > On Tue, Aug 15, 2017 at 5:54 AM, Tamas Penzes 
> > > wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > As far as I know the actual integration of HTrace 3.2 into HBase is
> > far
> > > > > from satisfying.
> > > > >
> > > > > This version of the library is old, buggy, not really maintained
> and
> > > the
> > > > > migration to version 4.x is quite hard (
> > > > > https://issues.apache.org/jira/browse/HBASE-14451) and looks like
> > the
> > > > task
> > > > > is not getting much closer to the goal.
> > > > >
> > > > > This is why I think we should remove HTrace now and if we still
> want
> > to
> > > > > have some art of tracing (I think it would be useful) then start it
> > > from
> > > > > the baseline.
> > > > > I have created a ticket for this task:
> > > > > https://issues.apache.org/jira/browse/HBASE-18601
> > > > > The removal could be quite fast and reach version 2.0.0 too.
> > > > >
> > > > > What do you all think?
> > > > >
> > > > > Thanks, Tamaas
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew
> > > >
> > > > Words like orphans lost among the crosstalk, meaning torn from
> truth's
> > > > decrepit hands
> > > >- A23, Crosstalk
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >- A23, Crosstalk
> >
>

Re: [DISCUSS] Remove HTrace 3.2.0-incubating from HBase

[Nick Dimiduk]

Agreed that ripping with no replacement would be too extreme and short
notice for 2.0.

On Tue, Aug 15, 2017 at 5:14 PM Andrew Purtell  wrote:

> > If Phoenix devs are advertising this feature to their users,
> > their contributions re: HBase and HDFS maintenance would be well
> received.
>
> The counter point to this more mindfulness on the part of HBase devs to
> interface compatibility impacts would go a long way. See HBASE-18431
> and PHOENIX-4076.
>
> Ripping out entirely the only tracing interfaces available is a more
> extreme example, although not without cause. (The state of HTrace.)
>
>
> On Tue, Aug 15, 2017 at 5:10 PM, Nick Dimiduk  wrote:
>
> > IMHO, we should be actively pruning half-implemented, testless, ownerless
> > code. HTrace queues up well for that chopping block. Long back I wanted
> to
> > see this particular feature though, but I cannot volunteer for the role
> > currently. If Phoenix devs are advertising this feature to their users,
> > their contributions re: HBase and HDFS maintenance would be well
> received.
> >
> > I question the choice of HTrace as the tool for the job, given the
> relative
> > lack of activity in that project vs. the myriad alternatives out there.
> > HTrace has been incubating for 2.5 years, has seen only 5 releases, with
> no
> > release in the last 18 months. I haven't evaluated the field in a while,
> > but there's probably something with much more mature tooling and support.
> > For instance, openzipkin/brave has much more activity more recently.
> >
> > -n
> >
> > On Tue, Aug 15, 2017 at 2:28 PM Stack  wrote:
> >
> > > On Tue, Aug 15, 2017 at 12:38 PM, Andrew Purtell 
> > > wrote:
> > >
> > > > Doc update to indicate HTrace is unfinished is fine.
> > > >
> > > >
> > > We could do this. Update jar and doc it as broke.
> > >
> > >
> > >
> > > > Phoenix uses HTrace to support query tracing. It "works".
> > >
> > >
> > > Nit: I didn't think this was htrace. It was an old version pulled into
> > > phoenix world where it lives storing to phoenix table reporting on
> > > phoenix-only spans.
> > >
> > >
> > >
> > > > A colleague made
> > > > a contribution to HDFS to fix a case where spans could get muddied
> > around
> > > > the WAL. We are carrying that patch on top of 2.7 for the moment but
> > IIRC
> > > > it's in 2.8.
> > > >
> > > > Removing all of our HBase level spans doesn't make sense to me when
> > spans
> > > > at HDFS level will not be removed, nor at the Phoenix level.
> > >
> > >
> > > The spans in hbase are just hanging until they get the htrace-4 revamp
> > and
> > > the dots get connected.
> > >
> > >
> > >
> > > > We hollow out
> > > > the middle. I think this is worse than leaving things at a half
> > finished
> > > > state. At least in the half finished state it might get finished.
> > > >
> > > >
> > > Nod.
> > >
> > >
> > >
> > > > What are the most pressing issues? I'm up for supporting an "HTrace"
> > get
> > > > well. I'll need your (community) help for getting patches into Hadoop
> > if
> > > > need be.
> > > >
> > > >
> > > HTrace needs care and a viewer (zipkin I think now it has come back
> > alive).
> > >
> > > HBase needs a couple of narratives wired through.
> > >
> > > Ditto HDFS.
> > >
> > > St.Ack
> > >
> > >
> > >
> > > >
> > > > On Tue, Aug 15, 2017 at 12:10 PM, Stack  wrote:
> > > >
> > > > > On Tue, Aug 15, 2017 at 11:22 AM, Andrew Purtell <
> > apurt...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > -1 to removing HTrace from HBase.
> > > > > >
> > > > > > Upgrade to the desired version, that would be fine.
> > > > > >
> > > > > >
> > > > > ​t​
> > > > >
> > > > > What you thinking Andrew?
> > > > >
> > > > > Trace is broke whether we upgrade or not. As is, we mislead. We
> give
> > > off
> > > > > the impression that hooking up hbase and hdfs via trace tells a
> story
> > > > about
> >

Re: [DISCUSS] Remove HTrace 3.2.0-incubating from HBase

[Nick Dimiduk]

On Tue, Aug 15, 2017 at 5:23 PM Sean Busbey  wrote:

> Say we replaced it with brave for 2.0, Phoenix tracing through to hdfs
> would be just as broken as if we pulled it out entirely, no?


Yep! From the perspective of Phoenix, HTrace API is our public API. We
should consider this as we do other places where 3rd party deps leak into
our API. Just as we removed Guava/Service, I suggest we should remove
HTrace/Span. If we want to support tracing, we should provide our own API
for it, and provide connective tissue for interop with whatever 3rd party
libs our users want to use. Or at least interfaces that downstreamers can
use to implement that connective tissue. HBase Spans -> HTrace Spans would
be a good demonstration of such an API, and give us what we need to restore
Span continuation through HDFS.

All this requires an owner, for which tracing in HBase has none. Maybe our
Tamas has some vested interest in being that owner, having brought up the
topic to start with?

On Aug 15, 2017 7:18 PM, "Nick Dimiduk"  wrote:
>
> > Agreed that ripping with no replacement would be too extreme and short
> > notice for 2.0.
> >
> > On Tue, Aug 15, 2017 at 5:14 PM Andrew Purtell 
> > wrote:
> >
> > > > If Phoenix devs are advertising this feature to their users,
> > > > their contributions re: HBase and HDFS maintenance would be well
> > > received.
> > >
> > > The counter point to this more mindfulness on the part of HBase devs to
> > > interface compatibility impacts would go a long way. See HBASE-18431
> > > and PHOENIX-4076.
> > >
> > > Ripping out entirely the only tracing interfaces available is a more
> > > extreme example, although not without cause. (The state of HTrace.)
> > >
> > >
> > > On Tue, Aug 15, 2017 at 5:10 PM, Nick Dimiduk 
> > wrote:
> > >
> > > > IMHO, we should be actively pruning half-implemented, testless,
> > ownerless
> > > > code. HTrace queues up well for that chopping block. Long back I
> wanted
> > > to
> > > > see this particular feature though, but I cannot volunteer for the
> role
> > > > currently. If Phoenix devs are advertising this feature to their
> users,
> > > > their contributions re: HBase and HDFS maintenance would be well
> > > received.
> > > >
> > > > I question the choice of HTrace as the tool for the job, given the
> > > relative
> > > > lack of activity in that project vs. the myriad alternatives out
> there.
> > > > HTrace has been incubating for 2.5 years, has seen only 5 releases,
> > with
> > > no
> > > > release in the last 18 months. I haven't evaluated the field in a
> > while,
> > > > but there's probably something with much more mature tooling and
> > support.
> > > > For instance, openzipkin/brave has much more activity more recently.
> > > >
> > > > -n
> > > >
> > > > On Tue, Aug 15, 2017 at 2:28 PM Stack  wrote:
> > > >
> > > > > On Tue, Aug 15, 2017 at 12:38 PM, Andrew Purtell <
> > apurt...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Doc update to indicate HTrace is unfinished is fine.
> > > > > >
> > > > > >
> > > > > We could do this. Update jar and doc it as broke.
> > > > >
> > > > >
> > > > >
> > > > > > Phoenix uses HTrace to support query tracing. It "works".
> > > > >
> > > > >
> > > > > Nit: I didn't think this was htrace. It was an old version pulled
> > into
> > > > > phoenix world where it lives storing to phoenix table reporting on
> > > > > phoenix-only spans.
> > > > >
> > > > >
> > > > >
> > > > > > A colleague made
> > > > > > a contribution to HDFS to fix a case where spans could get
> muddied
> > > > around
> > > > > > the WAL. We are carrying that patch on top of 2.7 for the moment
> > but
> > > > IIRC
> > > > > > it's in 2.8.
> > > > > >
> > > > > > Removing all of our HBase level spans doesn't make sense to me
> when
> > > > spans
> > > > > > at HDFS level will not be removed, nor at the Phoenix level.
> > > > >
> > > > >
> > > > > The spans in hbase are just hanging until they get the htrace-4
>

[RESULT][VOTE] First release candidate for HBase 1.1.12 (RC0) is available

[Nick Dimiduk]

With 5x binding and 1x votes to the affirmative and no other ballets cast,
this VOTE passes. Thanks to everyone who came out to check bits this cycle.

-n

On Sat, Aug 12, 2017 at 3:09 PM, Nick Dimiduk  wrote:

> I'm happy to announce the first release candidate of HBase 1.1.12
> (HBase-1.1.12RC0) is available for download at https://dist.apache.org/rep
> os/dist/dev/hbase/hbase-1.1.12RC0/
>
> Maven artifacts are also available in the staging repository
> https://repository.apache.org/content/repositories/orgapachehbase-1172
>
> Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
> available in the Apache keys directory https://people.apache.org/keys
> /committer/ndimiduk.asc and in our KEYS file
> http://www-us.apache.org/dist/hbase/KEYS.
>
> There's also a signed tag for this release at
> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=
> 29a930cdcbef2a64b601a110bad72955b3b04afc
>
> The detailed source and binary compatibility report vs 1.1.9 has been
> published for your review, at https://home.apache.org/~ndimi
> duk/1.1.11_1.1.12RC0_compat_report.html
>
> HBase 1.1.12 is the twelfth patch release in the HBase 1.1 line,
> continuing on the theme of bringing a stable, reliable database to the
> Hadoop and NoSQL communities. This release includes nearly 10 bug fixes
> since the 1.1.11 release. Notable correctness fixes include
> HBASE-9393, HBASE-15691, HBASE-18390, HBASE-18330.
>
> The full list of fixes included in this release is available at
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> ctId=12310753&version=12340864 and and in the CHANGES.txt file included
> in the distribution.
>
> Please try out this candidate and vote +/-1 by 23:59 Pacific time on
> Saturday, 2017-08-19 as to whether we should release these artifacts as
> HBase 1.1.12.
>
> Thanks,
> Nick
>

[ANNOUNCE] Apache HBase 1.1.12 is now available for download

[Nick Dimiduk]

The HBase team is happy to announce the immediate availability of HBase
1.1.12! Download it from an Apache mirror near you,
http://www.apache.org/dyn/closer.lua/hbase/, or wire up through the maven
repo.

Apache HBase is an open-source, distributed, versioned, non-relational
database. Apache HBase gives you low latency random access to billions of
rows with millions of columns atop non-specialized hardware. To learn more
about HBase, see https://hbase.apache.org/.

HBase 1.1.12 is the twelfth patch release in the HBase 1.1 line, continuing
on the theme of bringing a stable, reliable database to the Hadoop and
NoSQL communities. This release includes nearly 10 bug fixes since the
1.1.11 release. Notable correctness fixes include:

HBASE-9393 - Hbase does not closing a closed socket resulting in many
CLOSE_WAIT
HBASE-15691 - Port HBASE-10205 (ConcurrentModificationException in
BucketAllocator) to branch-1
HBASE-18390 - Sleep too long when finding region location failed
HBASE-18330 - NPE in ReplicationZKLockCleanerChore

The full list of fixes included in this release is available at
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310753&version=12340864
and and in the CHANGES.txt file included in the distribution.

Download through an ASF mirror near you:

https://www.apache.org/dyn/closer.lua/hbase/1.1.12

The relevant checksums files are available at:

https://www.apache.org/dist/hbase/1.1.12/hbase-1.1.12-src.tar.gz.mds
https://www.apache.org/dist/hbase/1.1.12/hbase-1.1.12-bin.tar.gz.mds

Project member signature keys can be found at

https://www.apache.org/dist/hbase/KEYS

PGP signatures are available at:

https://www.apache.org/dist/hbase/1.1.12/hbase-1.1.12-src.tar.gz.asc
https://www.apache.org/dist/hbase/1.1.12/hbase-1.1.12-bin.tar.gz.asc

For instructions on verifying ASF release downloads, please see

https://www.apache.org/dyn/closer.cgi#verify

Question, comments, and problems are always welcome at: dev@hbase.apache.org
.

Thanks to all the contributors who made this release possible!

Cheers,
The HBase Dev Team

Delaying 1.1.13 for another month

[Nick Dimiduk]

Heya folks,

There's slim commits to branch-1.1 over the last month. Looks like nothing
pressing by my eyes, so I'm going to let the branch simmer for another
month, let more changes accumulate. Will check back in with you in early
October.

Reply here if you have strong feeling to the contrary.

Kindly yours,
Nick

Re: DISCUSS: How can we have less branches?

[Nick Dimiduk]

Reviving this thread. I know our interest is around branch-2 right now, but
I think we are close to an actionable resolution here.

I'm a fan of Andrew's proposal of stabilizing our branch-1 for maintenance
releases, getting away from all the minors if we can. Do we have a quorum
of folks able and willing to do that work? Seems like it would center
around the 1.4 release.

If branch-1.1 retires in the next 2-6 months, are we happy with branch-1.2,
branch-1.3, or branch-1.4 carrying on the monthly cadence? Do we have a
strong need to continue 1.x once 2.x is out? Are we calling 1.2 the LTS
with quarterly patch releases, 1.3 aborted on arrival, and pushing folks
onto 2.x? Do we want to settle on quarterly or bi-annual minor releases and
only patch monthly or as necessary in between?

Thanks,
Nick

On Wed, Aug 9, 2017 at 8:00 AM, Mike Drob  wrote:

> One thing that we need to be super careful about after releasing 2.0 is
> that we don't accidentally introduce any incompatible changes. It's much
> harder to reason about forwards compatibility than backwards compatibility
> in my experience. So even though a hypothetical 1.5 would be released after
> 2.0, users would still have the expectation that a 1.5->2.0 upgrade would
> be smooth (unless we explicitly message that it isn't but that is a whole
> new set of problems).
>
> Also, to clarify some context here -- what is the difference between an LTS
> branch and a Stable branch? Don't they convey the same thing to users? As a
> relative newcomer, I feel like I missed an earlier conversation about this.
>
> Mike
>
> On Tue, Aug 8, 2017 at 10:45 PM, Phil Yang  wrote:
>
> > Another option is no 1.5/branch-1 any more. What new features we are
> going
> > to have in HBase 1.5 (if it will be released)? Backporting from branch-2
> to
> > branch-1 is not easy, so maybe we will not have any big feature in
> branch-1
> > after releasing 1.4. And if we release 1.5 after releasing 2.0, it may
> > confuse users. So IMO we can focus on branch-2 for new features.
> >
> > I think it will be good if we have fixed logic for EOL branches, for
> > example(just an example, can discuss):
> > 1:Release a final version and EOL 1.x after we think 1.x+1 is stable.
> > 2:Cut off new 1.x+2 branch after 1.x+1 is stable, don't cut too early.
> >
> > Then we will not need discussing each time for each branch EOL and we
> will
> > have a fixed number of maintaining branches.
> >
> > Thanks,
> > Phil
> >
> >
> > 2017-08-09 1:44 GMT+08:00 Andrew Purtell :
> >
> > > Well you are not wrong that branching was premature, it turns out. But
> > I'll
> > > roll with it...
> > >
> > >
> > > On Tue, Aug 8, 2017 at 10:43 AM, Zach York <
> zyork.contribut...@gmail.com
> > >
> > > wrote:
> > >
> > > > > I made branch-1.4 a few weeks ago only.
> > > >
> > > > Whoops, sorry for that! For some reason I thought I had seen it
> months
> > > ago.
> > > >
> > > > On Tue, Aug 8, 2017 at 10:40 AM, Andrew Purtell  >
> > > > wrote:
> > > >
> > > > > +1 from me on making 1.1 our LTS. Either 1.1 or 1.2 are
> candidates. I
> > > > think
> > > > > 1.1 has the edge because it lacks locking changes introduced into
> > 1.2,
> > > > just
> > > > > like 1.2 lacks locking changes introduced in 1.3 - the latter of
> > which
> > > > has
> > > > > had far reaching consequences, and the former not an insignificant
> > > change
> > > > > either.
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Aug 8, 2017 at 10:31 AM, Nick Dimiduk 
> > > > wrote:
> > > > >
> > > > > > On Tue, Aug 8, 2017 at 9:15 AM Mike Drob 
> wrote:
> > > > > >
> > > > > > > > The discussion also brought up the notion of an LTS release
> > line.
> > > > I'm
> > > > > > not
> > > > > > > > sure how this jives with the more fequent minors, but would
> > > require
> > > > > > some
> > > > > > > > branch that's so stable that an RM can effectively spin
> > releases
> > > > > blind.
> > > > > > >
> > > > > > > Seems to me like this branch would necessarily need to be very
> > > > > > > backport-light? Only the top of the highest priority issues
> would
> > > be
> > >

Post-release RM duties

[Nick Dimiduk]

Heya,

I noticed tonight that I've been remiss in closing tickets after the dust
settles around a release. I think it's something I/we did, once upon a
time. However, I don't see any mention of it in the ref guide around
releases. Is this something that should be done? Can you point me to our
existing policy on this? I'm happy to go back through and close out
tickets, just give me the affirmative on it being policy we want enforced.

For that matter I don't see much of anything in the way of guidelines for
RMs re: post-release processing. Seems worthy of a new section. I have my
post-VOTE steps outlined at the bottom of my crib sheet [0]. Should I/we
flesh this out in our documentation?

Thanks,
Nick

[0]: https://gist.github.com/ndimiduk/924db7f5ee75baa67802

Re: Performance issue in the Join query on the HBase tables

[Nick Dimiduk]

Have you considered running Hive/Spark over snapshots of your HBase tables?

If you're seeing network saturation over HBase but not hdfs, makes me think
data locality is not being honored. Might be worth investigating as well.

On Fri, Sep 29, 2017 at 3:26 AM wenxing zheng 
wrote:

> Dear all,
>
> I have 3 big HBase tables, which all have millions of rows(rows are synced
> from MySQL DB via Bin log) and for each HBase table, we have an external
> table on Hive correspondingly with the storage by
> 'org.apache.hadoop.hive.hbase.HBaseStorageHandler'. The advantage is that
> we can always keep sync up with the production DB and provides random
> access by key.
>
> Now our business needs to do some analysis on those tables with Join query.
> What's the best practice to make it?
>
> From my experiment, I found that with the Spark SQL on HBase or Hive, the
> job ran very slowly and will saturate the network bandwidth. But it works
> very well for the Hive SQL directly against Hive from HDFS files(make a
> copy of the data to HDFS files).
>
> Appreciated for any advice on what would be the problem here? and the way
> to optimize the job.
> Regards, Wenxing
>

Re: Delaying 1.1.13 for another month

[Nick Dimiduk]

Our beloved branch-1.1 is still showing only the most minor product
changes. Almost everything since 1.1.12 is build, test related. Once again,
I'll let it continue on the back-burner for another month, unless someone
speaks up.

Same time next month,
-n

On Mon, Sep 18, 2017 at 9:04 PM, Nick Dimiduk  wrote:

> Heya folks,
>
> There's slim commits to branch-1.1 over the last month. Looks like nothing
> pressing by my eyes, so I'm going to let the branch simmer for another
> month, let more changes accumulate. Will check back in with you in early
> October.
>
> Reply here if you have strong feeling to the contrary.
>
> Kindly yours,
> Nick
>

Re: Is our maven build order correct? Do we have required jars in binary/source tar.gz?

[Nick Dimiduk]

IMHO, you go to the bin.tgz for a runnable executable. Everything else
(archetypes, client jars, sources) is pulled down from Maven Central
through dev tooling. I don't see a strong need for ops to receive the
latter in the bin.tgz. The only use I can think of is ignoring someone
wants to automate a complex mirror situation based on the content of a
single download. That's a bit of a stretch.

That said, maybe the Foundation mandates the completeness of a binary
convenience release?

On Wed, Oct 25, 2017 at 7:14 PM Stack  wrote:

> On Wed, Oct 25, 2017 at 3:03 PM, Sean Busbey  wrote:
>
> > Thus far, the shaded jars and the archetypes have only been aimed at
> > consumption during downstream build processes. Namely folks using maven
> to
> > build an app.
> >
> > For those users, only being published in the Apache Nexus repo matters,
> so
> > we deployed there (via the deploy step of our release process with
> release
> > and apache-release maven profiles). We have not, thus far, included those
> > jars in our binary tarball. Thus they aren't listed as dependencies of
> the
> > assembly module and get built after it.
> >
> > Adding them would nearly double our binary tarball size, so I'm inclined
> to
> > not include them without a compelling use case.
> >
> >
> Interesting. I'd have said our bin should have all our built product but
> yeah, as you say, archetypes depends on maven context and would make no
> sense in bin tgz.
>
> If we want to evangelize shaded client as primary access point, would that
> be justification bundling it in bin tgz?
>
>
>
> > The source tarball isn't made by a module, despite the descriptor living
> in
> > the hbase-assembly module. It could just as easily be in dev-support. The
> > step of our release process that creates the source tarball does a manual
> > invocation of the maven assembly plug-in and points at the source
> > descriptor directly.
> >
> >
> Our build could do w/ a revamp. It still has a form from when we used emit
> multiple products, src and a bin tarball for hadoop1 and hadoop2.
>
> St.Ack
>
>
>
>
> > On Oct 25, 2017 4:57 PM, "Apekshit Sharma"  wrote:
> >
> > Hi folks,
> >
> > Found some discrepancies in moduleSet  list in src.xml and
> > hadoop-two-compat.xml. Got a crash course on hbase-assembly today by
> stack.
> > Throwing some larger questions here;
> >
> > 1. Do we want h-archetypes in binary tar?
> > 2. Shouldn't we be building h-shaded, h-examples and h-archetypes before
> > h-assembly so that the corresponding jars get included in source/binary
> > tar? Here's the current build order :
> >
> > 
> > Apache HBase - Archetypes .. SUCCESS [  0.006 s]
> > Apache HBase - Assembly  SUCCESS [  0.281 s]
> > Apache HBase - Shaded .. SUCCESS [  0.006 s]
> > Apache HBase - Shaded - Client . SUCCESS [  0.010 s]
> > Apache HBase - Shaded - MapReduce .. SUCCESS [  0.011 s]
> > Apache HBase Shaded Packaging Invariants ... SUCCESS [  0.007 s]
> > Apache HBase - Exemplar for hbase-client archetype . SUCCESS [  0.096 s]
> > Apache HBase - Exemplar for hbase-shaded-client archetype SUCCESS [
> 0.095
> > s]
> > Apache HBase - Archetype builder ... SUCCESS [  0.008 s]
> >
> >
> > -- Appy
> >
>

Re: Delaying 1.1.13 for another month

[Nick Dimiduk]

On Thu, Oct 26, 2017 at 9:06 AM Mike Drob  wrote:

> Hi Nick,
>
> What do you think of my suggestion?


Pardon me Mike, didn't mean to ignore your suggestion. I was waiting for a
few more voices to chime in here. I think your suggestion is the right
choice. 1.1 backports have slowed to a crawl and 1.2 has been marked stable
for some time.

On Wed, Oct 18, 2017 at 10:09 AM, Mike Drob  wrote:
>
> > Maybe we do a final release on it and then EOL the branch?
> >
> > On Fri, Oct 13, 2017 at 5:25 PM, Nick Dimiduk 
> wrote:
> >
> >> Our beloved branch-1.1 is still showing only the most minor product
> >> changes. Almost everything since 1.1.12 is build, test related. Once
> >> again,
> >> I'll let it continue on the back-burner for another month, unless
> someone
> >> speaks up.
> >>
> >> Same time next month,
> >> -n
> >>
> >> On Mon, Sep 18, 2017 at 9:04 PM, Nick Dimiduk 
> >> wrote:
> >>
> >> > Heya folks,
> >> >
> >> > There's slim commits to branch-1.1 over the last month. Looks like
> >> nothing
> >> > pressing by my eyes, so I'm going to let the branch simmer for another
> >> > month, let more changes accumulate. Will check back in with you in
> early
> >> > October.
> >> >
> >> > Reply here if you have strong feeling to the contrary.
> >> >
> >> > Kindly yours,
> >> > Nick
> >> >
> >>
> >
> >
>

Re: Struggles around Cell#getType()

[Nick Dimiduk]

On Fri, Oct 27, 2017 at 9:58 AM, Josh Elser  wrote:

> Re-reading https://issues.apache.org/jira/browse/HBASE-8693 that Sergey
> pointed out, I more think that the maybe getType() was misintepreted from
> what Nick originally meant it to be. Maybe intentional, maybe not.
>

The classes under o.a.h.h.types are for helping users building applications
to represent their application data in HBase byte arrays. See the overview
in the package description [0]. One uses implementations of
o.a.h.h.types.DataType to encode values that can then be stored in
o.a.h.h.Cells -- as the row, the column qualifier, or column value. The
type of the Cell is its use within the KeyValue storage engine that is
HBase while the DataType describes a means of getting some Java object
value into or out of a byte array.

[0]:
http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/types/package-summary.html#package.description

On 10/27/17 7:29 AM, Chia-Ping Tsai wrote:
>
>> The CellBuilder#Data type is introduced to make sure all components used
>> to builder cell are IA.Public.
>>
>> bq. Best as I can tell, Cell#getType() should be deprecated
>> As i see it, the Cell#getType, #getTimestamp, #getSequenceId, and #getTag
>> should be deprecated as these methods is some kind of internal info of
>> storage engine. As a key-value store, the key  consisting of row, family,
>> and qualifier is enough to the general purpose. Other fields belong to the
>> specific storage engine, and they should not be in the Cell which is our
>> "frontline" interface of data.
>>
>>
>> On 2017-10-27 06:40, Josh Elser  wrote:
>>
>>> Hiya,
>>>
>>> (Background: see HBASE-19002)
>>>
>>> In trying to write some example Observers, I found myself in a pickle:
>>> how do I tell if a Cell is a Put?
>>>
>>> * Cell#getType() returns a byte which corresponds to a KeyValue.Type
>>> * KeyValue.Type has API to convert a byte to Type
>>> * KeyValue (and thus KeyValue.Type) is IA.Private
>>> * DataType o.a.h.h.typesDataType _appears to me_ to be the replacement
>>> for the KeyValue.Type
>>>
>>> Best as I can tell, Cell#getType() should be deprecated and we should
>>> have some kind of API (method on Cell or CellUtil) which returns a
>>> DataType instead of Type. The details of the byte and the KeyValue.Type
>>> should be hidden inside the implementation.
>>>
>>> My hunch is that this is an accidental omission, but Stack recommended
>>> that I "ask the class" ;). What have I missed? I think this is trivial
>>> to fix; obviously, I don't want to make a fix if I just didn't look hard
>>> enough.
>>>
>>> Thanks!
>>>
>>> - Josh
>>>
>>>

Re: Is our maven build order correct? Do we have required jars in binary/source tar.gz?

[Nick Dimiduk]

On Wed, Oct 25, 2017 at 9:53 PM, Sean Busbey  wrote:

>
> okay so here's a use case. our return from `hbase classpath` is a
> nightmare. if you're a downstream user that just wants "hey hbase give
> me jars I need to run against you right now." it's garbage. we could
> include the shaded jars and return the shaded client for something
> like `hbase classpath-client`. Same with replacing `hbase mapredcp`
> current output with the shaded mapreduce jar.
>

I think the listing of dependencies provided by `hbase classpath` family of
utilities an anti-pattern in light of shaded artifacts. Can we replace
these commands with instructions to build your application jar with the
appropriate dependencies? Are there use-cases where the user doesn't
control their classpath, they have no choice but to use `hadoop`/`yarn` to
launch their application instead of `hbase`?

Re: [DISCUSS] Any committers willing to do maintenance releases over the holidays?

[Nick Dimiduk]

As 1.1 is rounding down, I will be able to apply that time to helping out
on another release line, if that's useful to the community.

Thanks,
Nick

On Mon, Oct 30, 2017 at 9:35 PM, Sean Busbey  wrote:

> Hi folks!
>
> I'm in the process of getting us a 1.2.7-RC, hopefully soon[1]. This
> release is badly behind schedule. I'd very much like to get us back on
> a regular cadence for our stable release line, with a goal of once a
> month. Unfortunately, I'm very unlikely to have time to do release
> managing after the 1.2.7 release until spring (luckily it's for
> fortunate-to-me reasons).
>
> Despite the delay in schedule on this release, generally doing a
> maintenance release is relatively low effort. These kinds of
> "substitute RM" situations are a great chance to get familiar with the
> process while having a well-defined end point. If there's anyone who'd
> like to give it a try by handling things while I'm gone, both I and
> I'm sure the project community would be grateful.
>
> To take on this particular task, one must be a committer already (due
> to ASF policy). It's a great way to "act like a PMC" for those
> committers who'd like to make a long term investment in HBase.
>
> Anyone interested?
>
> -busbey
>
> [1]: https://issues.apache.org/jira/browse/HBASE-18276
>

Re: DISCUSSION: Minimum hbase1 version from which you can upgrade to hbase2 (1.2.x?)

[Nick Dimiduk]

1.2 is good, but are we aware of anything that precludes 1.1? 0.98? On disk
compatibility (HFile, WAL, AMv2) should be the limiting factor here, right?
Wire protocols have been compatible all the while...

On Fri, Nov 3, 2017 at 5:56 PM Zach York 
wrote:

> +1 for having the minimum (supported) hbase1 version be 1.2.x.
>
> On Fri, Nov 3, 2017 at 5:30 PM, Stack  wrote:
>
> > Over in the adjacent "[DISCUSS] hbase-2.0.0 compatibility expectations"
> > thread, we chatted some on what would be the minimum hbase-1.x version
> from
> > which you can upgrade to hbase-2.
> >
> > The last statement made on this topic by Sean was that only upgrades from
> > 1.2.x, our current stable offering, or later should be supported.
> >
> > There was no dissent.
> >
> > We all good w/ this? Speak up if you disagree else 1.2.x becomes the
> > 'official' minimum.
> >
> > NOTES:
> >
> > + We need to agree on a minimum so we know what migrations to test.
> > + It might be possible to upgrade from versions before 1.2.x but we (or
> at
> > least I -- smile) won't have tried it or run verifications to ensure all
> > made it over (let us know if you successfully migrate from a baseline
> that
> > precedes 1.2).
> > + Hopefully we can avoid requiring Users move to the latest on the 1.2
> > branch. This shouldn't be necessary doing a stop/start upgrade. It might
> be
> > needed doing a rolling upgrade. Lets see.
> >
> > Thanks,
> > St.Ack
> >
>

Final 1.1 release

[Nick Dimiduk]

Hello!

By (extremely) lazy consensus, it's looking like the final release of HBase
1.1 will be lucky number 1.1.13. I'd like to publish a release candidate
after the US Thanksgiving holiday, let's say on or around Monday, Nov 27.

That said, there is one think that I think may delay, or at least be good
reason to make a subsequent release. If the conclusion of the thread on
upgrades to 2.0 finds some minor issue excluding 1.1 as a viable upgrade
path, I would like to get them fixed. That would be reason enough to
warrant a follow up release.

Thanks for your attention.
Nick

Re: [DISCUSS] Any committers willing to do maintenance releases over the holidays?

[Nick Dimiduk]

Sean,

Do you have a target date you'd like to see the community aiming for on
this one?

If you don't mind, I would propose the Release Wrangler get started in JIRA
pruning and test suite kicking over the next couple weeks, and we can
target the first or second week of Dec. There's been quite a few commits
since the last release, so there may be some surprises lurking for our
volunteers to sort out. A good place to start is the compatibility report.

Who will carry this banner? Apekshit, Jan: shall we draw straws? One of you
have a bit of extra free time over the next 4 weeks?

Thanks,
Nick

On Wed, Nov 1, 2017 at 11:33 AM Jan Hentschel <
jan.hentsc...@ultratendency.com> wrote:

> I also like to volunteer, but I don’t think that I can do it on my own.
>
>
>
> Jan
>
>
>
> From: Apekshit Sharma 
> Reply-To: 
> Date: Wednesday, November 1, 2017 at 12:24 AM
> To: 
> Subject: Re: [DISCUSS] Any committers willing to do maintenance releases
> over the holidays?
>
>
>
> Loads of helping hands...woohoo!
>
>
>
> -Appy
>
>
>
>
>
> On Oct 31, 2017 4:01 PM, "Nick Dimiduk"  wrote:
>
>
>
> As 1.1 is rounding down, I will be able to apply that time to helping out
>
> on another release line, if that's useful to the community.
>
>
>
> Thanks,
>
> Nick
>
>
>
> On Mon, Oct 30, 2017 at 9:35 PM, Sean Busbey  wrote:
>
>
>
> > Hi folks!
>
> >
>
> > I'm in the process of getting us a 1.2.7-RC, hopefully soon[1]. This
>
> > release is badly behind schedule. I'd very much like to get us back on
>
> > a regular cadence for our stable release line, with a goal of once a
>
> > month. Unfortunately, I'm very unlikely to have time to do release
>
> > managing after the 1.2.7 release until spring (luckily it's for
>
> > fortunate-to-me reasons).
>
> >
>
> > Despite the delay in schedule on this release, generally doing a
>
> > maintenance release is relatively low effort. These kinds of
>
> > "substitute RM" situations are a great chance to get familiar with the
>
> > process while having a well-defined end point. If there's anyone who'd
>
> > like to give it a try by handling things while I'm gone, both I and
>
> > I'm sure the project community would be grateful.
>
> >
>
> > To take on this particular task, one must be a committer already (due
>
> > to ASF policy). It's a great way to "act like a PMC" for those
>
> > committers who'd like to make a long term investment in HBase.
>
> >
>
> > Anyone interested?
>
> >
>
> > -busbey
>
> >
>
> > [1]: https://issues.apache.org/jira/browse/HBASE-18276
>
> >
>
>
>
>
>
>

[VOTE] First release candidate for HBase 1.1.13 (RC0) is available

[Nick Dimiduk]

I'm happy to announce the first release candidate of HBase 1.1.13
(HBase-1.1.13RC0) is available for download at
*https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.13RC0/
*.

This is to be the final release from branch-1.1.

Maven artifacts are available in the staging repository
*https://repository.apache.org/content/repositories/orgapachehbase-1182
*

Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
available in the Apache keys directory https://people.apache.org/keys
/committer/ndimiduk.asc and in our KEYS file http://www-us.apache.org/dist/
hbase/KEYS.

There's also a signed tag for this release at
*https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=16a04e6629e614c7900c443f3a29cdba92dd7b7e
*

The detailed source and binary compatibility report vs 1.1.12 has been
published for your review, at
*https://home.apache.org/~ndimiduk/1.1.12_1.1.13RC0_compat_report.html
*

HBase 1.1.13 is the thirteenth and final patch release in the HBase 1.1
line, continuing on the theme of bringing a stable, reliable database to
the Hadoop and NoSQL communities. This release includes over 40 resolved
issues since the 1.1.12 release; the majority of these changes are to build
tooling rather than the product itself. Notable product correctness fixes
include HBASE-18665 and HBASE-19052.

The full list of fixes included in this release is available at
*https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310753&version=12341346
*
and
and in the CHANGES.txt file included in the distribution.

Please try out this candidate and vote +/-1 by 23:59 Pacific time on
Friday, 2017-12-08 as to whether we should release these artifacts as HBase
1.1.13.

Thanks,
Nick

Re: [VOTE] First release candidate for HBase 1.1.13 (RC0) is available

[Nick Dimiduk]

 Thanks for the pointer, Andrew. This worked for me and I was able
> to
> > > > start
> > > > >> hbase now and can resume testing.
> > > > >>
> > > > >> I didn't mean to imply that Nick needs to create human release
> > notes,
> > > > but
> > > > >> wanted to know if he had considered it in light of the plan to do
> so
> > > for
> > > > >> 1.4.0. I think it's a nice to have, but definitely not critical.
> > > > >>
> > > > >> (I'm still -1 due to the tar/tag discrepancy, however.)
> > > > >>
> > > > >> On Mon, Dec 4, 2017 at 11:05 AM, Andrew Purtell <
> > > > andrew.purt...@gmail.com
> > > > >> >
> > > > >> wrote:
> > > > >>
> > > > >> > I think you need to delete $TMPDIR/hbase-mdrob (or whatever is
> > your
> > > > >> > username) before testing the binaries. Looks like you've been
> > > testing
> > > > a
> > > > >> > later version and it's left data behind.
> > > > >> >
> > > > >> > We have not produced release notes beyond the JIRA generated
> ones
> > > for
> > > > >> > prior releases. We will soon. This is something I agreed to for
> > > > 1.4.0. I
> > > > >> > don't think it's fair to expect Nick to do it for the last 1.1.x
> > > > release
> > > > >> > when it hasn't been done prior, but I'm not saying don't do it
> if
> > he
> > > > >> wants
> > > > >> > to.
> > > > >> >
> > > > >> >
> > > > >> > > On Dec 4, 2017, at 8:43 AM, Mike Drob 
> wrote:
> > > > >> > >
> > > > >> > > -1 (non-binding)
> > > > >> > >
> > > > >> > > general:
> > > > >> > > + sign, sums good
> > > > >> > >
> > > > >> > > src:
> > > > >> > > - tar missing hbase-native-client (present in tag)
> > > > >> > > + can build from source (oracle jdk 1.7.0_80)
> > > > >> > >
> > > > >> > > bin:
> > > > >> > > - docs/doap_Hbase.rdf is very out of date (possibly not
> actually
> > > an
> > > > >> > issue)
> > > > >> > > - unable to launch using bin/hbase-start.sh (both java 7 and
> 8),
> > > got
> > > > >> > > following error in .out log file:
> > > > >> > >
> > > > >> > > WARNING! HBase file layout needs to be upgraded. You have
> > version
> > > > null
> > > > >> > and
> > > > >> > > I want version 8. Consult http://hbase.apache.org/book.html
> for
> > > > >> further
> > > > >> > > information about upgrading HBase. Is your hbase.rootdir
> valid?
> > If
> > > > so,
> > > > >> > you
> > > > >> > > may need to run 'hbase hbck -fixVersionFile'.
> > > > >> > >
> > > > >> > >
> > > > >> > > System Info:
> > > > >> > >
> > > > >> > > mdrob@mdrob-MBP:/tmp/hbase-1.1-0/hbase-1.1.13$ sw_vers
> > > > >> > > ProductName: Mac OS X
> > > > >> > > ProductVersion: 10.12.6
> > > > >> > > BuildVersion: 16G1036
> > > > >> > > mdrob@mdrob-MBP:/tmp/hbase-1.1-0/hbase-1.1.13$ java -version
> > > > >> > > java version "1.7.0_80"
> > > > >> > > Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> > > > >> > > Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed
> mode)
> > > > >> > >
> > > > >> > >
> > > > >> > > Mike
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >> On Fri, Dec 1, 2017 at 12:31 AM, Nick Dimiduk <
> > > ndimi...@apache.org
> > > > >
> > > > >> > wrote:
> > > > >> >

Re: Removing hbase-native-client (HBASE-19419)

[Nick Dimiduk]

On Mon, Dec 4, 2017 at 3:28 PM, Josh Elser  wrote:

> Makes sense to me.
>
> *soapbox* I think focusing on https://issues.apache.org/jira
> /browse/HBASE-14850 would be a better use of time than trying to
> revitalize the old stuff (which I assume has begun to rot).


Is the code under hbase-native-client not the same as that referenced by
HBASE-14850? The patches on said ticket's children land code under the same
path.

On 12/4/17 3:00 PM, Andrew Purtell wrote:
>
>> Mike Drob pointed me at HBASE-19176, where hbase-native-client has already
>> been removed from branch-2 given a similar rationale. Therefore I intend
>> to
>> do the same for branch-1.4 and branch-1. On HBASE-19419 Mike asked if
>> hbase-native-client would be removed from branch-1.1, branch-1.2, and
>> branch-1.3 as well. I can do that, but would like to hear from the
>> respective branch RMs if possible first.
>>
>> On Mon, Dec 4, 2017 at 11:43 AM, Andrew Purtell 
>> wrote:
>>
>> We had a recent non-binding veto in a release candidate vote (for 1.1.13)
>>> due to, I think, legitimate confusion over the status of the
>>> hbase-native-client subdirectory in our source tree. This is a self
>>> contained native code connector that is not hooked up to our Maven build.
>>> Therefore there isn't an automated way for our RMs to produce binary
>>> convenience artifacts that include this component. I'm not even sure it
>>> is
>>> buildable or functional at this point. It has not been updated for two
>>> years.
>>>
>>> Because it is self contained, and in what appears to be an unmaintained
>>> state, I would like to remove it for the 1.4.0 release, therefore from
>>> branch-1.4 and up. Dropping it doesn't represent a compatibility problem
>>> in
>>> my view as it isn't hooked up to the build and seems unlikely anyone is
>>> depending on it given we haven't had a single change nor issue reported
>>> against it for two years.
>>>
>>> If someone does care about this, it can be resurrected at any time as an
>>> independent GitHub based project.
>>>
>>> --
>>> Best regards,
>>> Andrew
>>>
>>> Words like orphans lost among the crosstalk, meaning torn from truth's
>>> decrepit hands
>>> - A23, Crosstalk
>>>
>>>
>>
>>
>>

Re: branch-1 policy for builds against Hadoop 3.0.0

[Nick Dimiduk]

On Mon, Dec 4, 2017 at 3:30 PM, Josh Elser  wrote:

> +1 not release blockers
>
> This stems from this line of thinking:
>
> * Hadoop does not dictate HBase's release schedule (except in extenuating
> circumstances)
> * HBase can't ensure compatibility against something that does not yet
> exist


Agreed.

On 12/4/17 3:43 PM, Andrew Purtell wrote:
>
>> Does anyone view compilation problems against Hadoop 3.0.0 in branch-1 as
>> a
>> release blocker? See HBASE-19421.
>>
>> In my view
>> ​, use of Hadoop 3 with branch-1 HBase is not something we are going to
>> recommend for production use for some time, and Hadoop 3.0.0 is not even
>> GA
>> yet. (I know it may be close.) Therefore, builds that work with it are
>> nice
>> to have, but not essential. Compilation problems found for e.g. 1.4.0 can
>> be fixed for subsequent release 1.4.1.
>>
>> ​Please speak up if you disagree.  Let's discuss this before we have a RC
>> vote where it may come up.
>>
>> --
>> Best regards,
>> Andrew
>>
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>> - A23, Crosstalk
>>
>>

Re: [VOTE] First release candidate for HBase 1.1.13 (RC0) is available

[Nick Dimiduk]

No one has voted a binding -1 with actionable changes, so as far as I'm
concerned this RC remains valid. If people need more time, we can extend
this vote.

Thanks,
Nick

On Thu, Dec 7, 2017 at 8:07 AM, Ted Yu  wrote:

> Nick:
> Originally you set tomorrow as deadline.
>
> Is there a new RC coming out (w.r.t. Mike's comment) ?
>
> Cheers
>
> On Mon, Dec 4, 2017 at 8:37 PM, Nick Dimiduk  wrote:
>
> > Mike:
> >
> > > Do you plan to make a human-readable set of release notes in addition
> to
> > the list of JIRA issues resolved?
> >
> > Not as such. For all branch-1.1 releases, I've written up a little
> > human-friendly summary in the ANNOUNCE email. Basically, expanding on the
> > list of JIRA tickets I highlight in the RC notes to include their full
> > ticket summaries. I haven't followed the details of the branch-1.4
> release
> > line, so I'm not sure what additional information you might be hoping
> for.
> >
> > > tar missing hbase-native-client (present in tag)
> >
> > That's been the case since rel/1.1.0. We as a community have never
> shipped
> > a binary native client in this release line and we've never claimed that
> > the native sources packaged herein are ready for production consumption.
> > They probably should have been dropped from the branch before initial
> > release, but that was not done. I have no objection to dropping them
> from a
> > branch-1.1 release; from the git log, I see no commit activity to that
> > module since Jan 2014. I don't see any of this as a blocker for this RC.
> >
> > > WARNING! HBase file layout needs to be upgraded ...
> >
> > When I test these RC's on a Mac, I explicitly set hbase.tmp.dir to a
> > location specific to the candidate I've unpacked. This has the benefit
> > avoiding cross-version conflicts and other weirdness of Mac tmp directory
> > management. For instance,
> >
> > 
> >
> > hbase.tmp.dir/tmp/hbase-1.1.
> > 13/tmp
> > 
> >
> > Peter:
> >
> > > In the logs I saw this line. Source code repository URL looks
> incorrect.
> > > 2017-12-04 10:13:27,028 INFO  [main] util.VersionInfo: Source code
> > repository *git://diocles.local/Volumes/hbase-1.1.13/hbase*
> > revision=c64bf8a9f35352cd504f2b8f4b02f9148cf45ab6
> >
> > Looking through the log, HBASE-16538 /
> > 851c89af6ef9a78e2e3bc9ad3153367e85731c81 looks suspicious. It looks like
> > that change first shipped in 1.1.7. Indeed, I see the equivelant line in
> > the binary release of 1.1.12.
> >
> > On Mon, Dec 4, 2017 at 4:12 PM, Stack  wrote:
> >
> > > On Mon, Dec 4, 2017 at 11:52 AM, Andrew Purtell 
> > > wrote:
> > >
> > > > > I think this can be fixed by using `git archive` to generate the
> src
> > > tar
> > > > instead of the src assembly.
> > > >
> > > > We could update the make_rc.sh script to create the source tarball in
> > > this
> > > > way. Would you be willing to make a patch for that?
> > > >
> > > >
> > > (I think you fellows already figured this going by JIRA movement)
> > >
> > > HBASE-19152 "Update refguide 'how to build an RC' and the make_rc.sh
> > > script" changed make_rc.sh to use git archive. Wasn't backported
> though.
> > > S
> > >
> > >
> > >
> > > > For release 1.4.0 and up though I propose we remove
> hbase-native-client
> > > as
> > > > unmaintained. It can be resurrected as an independent project on
> GitHub
> > > if
> > > > any interested parties show up.
> > > >
> > > >
> > > >
> > > > On Mon, Dec 4, 2017 at 11:45 AM, Mike Drob  wrote:
> > > >
> > > > > I think I used some shorthand earlier and ambiguously represented
> my
> > > > > problem. The issue is that native is missing from the _source_
> > > tarball. I
> > > > > completely understand why it would be missing from the binary
> > tarball,
> > > > > maintaining native binaries is a huge hassle and not in our scope,
> > IMO.
> > > > >
> > > > > However, I think it is fair for users to expect that they can
> > download
> > > > our
> > > > > source release, and build a native client from there. Or at least
> it
> > > will
> > > > > have native code. They shouldn't need to go to 

Re: [VOTE] First release candidate for HBase 1.1.13 (RC0) is available

[Nick Dimiduk]

+1

- verified tarballs vs public key on people.apache.org.
- extracted bin tgz:
  - inspect structure. look good.
  - with jdk1.8.0_65:
- run LoadTestTool against standalone bin tgz with FAST_DIFF block
encoder and ROWCOL blooms. No issues, logs look good.
- poked around webUI. looks good.
  - load the site, browsed book.
- extracted src tgz:
  - inspect structure. look good.
  - run LoadTestTool against standalone built from src tgz with FAST_DIFF
block encoder and ROWCOL blooms. No issues, logs look good.
  - poked around webUI. looks good.
- ran the hbase-downstreamer project vs. the staged maven repository. tests
pass.

On Thu, Dec 7, 2017 at 1:44 PM, Ted Yu  wrote:

> +1
>
> Checked sums and signatures: ok
> Ran unit tests: passed
> Started standalone cluster and did some basic operations
>
> On Thu, Dec 7, 2017 at 1:14 PM, Andrew Purtell 
> wrote:
>
> > +1
> >
> > Checked sums and signatures: ok
> > Checked compat report: ok
> > RAT check passed: ok (7u80)
> > Built from source: ok (7u80)
> > Unit tests pass: ok (8u131)
> > 1M row LTT: ok (8u131)
> >
> >
> > On Thu, Dec 7, 2017 at 8:40 AM, Nick Dimiduk 
> wrote:
> >
> > > No one has voted a binding -1 with actionable changes, so as far as I'm
> > > concerned this RC remains valid. If people need more time, we can
> extend
> > > this vote.
> > >
> > > Thanks,
> > > Nick
> > >
> > > On Thu, Dec 7, 2017 at 8:07 AM, Ted Yu  wrote:
> > >
> > > > Nick:
> > > > Originally you set tomorrow as deadline.
> > > >
> > > > Is there a new RC coming out (w.r.t. Mike's comment) ?
> > > >
> > > > Cheers
> > > >
> > > > On Mon, Dec 4, 2017 at 8:37 PM, Nick Dimiduk 
> > > wrote:
> > > >
> > > > > Mike:
> > > > >
> > > > > > Do you plan to make a human-readable set of release notes in
> > addition
> > > > to
> > > > > the list of JIRA issues resolved?
> > > > >
> > > > > Not as such. For all branch-1.1 releases, I've written up a little
> > > > > human-friendly summary in the ANNOUNCE email. Basically, expanding
> on
> > > the
> > > > > list of JIRA tickets I highlight in the RC notes to include their
> > full
> > > > > ticket summaries. I haven't followed the details of the branch-1.4
> > > > release
> > > > > line, so I'm not sure what additional information you might be
> hoping
> > > > for.
> > > > >
> > > > > > tar missing hbase-native-client (present in tag)
> > > > >
> > > > > That's been the case since rel/1.1.0. We as a community have never
> > > > shipped
> > > > > a binary native client in this release line and we've never claimed
> > > that
> > > > > the native sources packaged herein are ready for production
> > > consumption.
> > > > > They probably should have been dropped from the branch before
> initial
> > > > > release, but that was not done. I have no objection to dropping
> them
> > > > from a
> > > > > branch-1.1 release; from the git log, I see no commit activity to
> > that
> > > > > module since Jan 2014. I don't see any of this as a blocker for
> this
> > > RC.
> > > > >
> > > > > > WARNING! HBase file layout needs to be upgraded ...
> > > > >
> > > > > When I test these RC's on a Mac, I explicitly set hbase.tmp.dir to
> a
> > > > > location specific to the candidate I've unpacked. This has the
> > benefit
> > > > > avoiding cross-version conflicts and other weirdness of Mac tmp
> > > directory
> > > > > management. For instance,
> > > > >
> > > > > 
> > > > >
> > > > > hbase.tmp.dir/tmp/hbase-1.1.
> > > > > 13/tmp
> > > > > 
> > > > >
> > > > > Peter:
> > > > >
> > > > > > In the logs I saw this line. Source code repository URL looks
> > > > incorrect.
> > > > > > 2017-12-04 10:13:27,028 INFO  [main] util.VersionInfo: Source
> code
> > > > > repository *git://diocles.local/Volumes/hbase-1.1.13/hbase*
> > > > > revision=c64bf8a9f35352cd504f2b8f4b02f9148cf45ab6
> > > &

Re: [VOTE] First release candidate for HBase 1.1.13 (RC0) is available

[Nick Dimiduk]

At close of the period, this VOTE has received 3x binding +1's, a
non-binding +1, and a non-binding -1, with no other votes cast.

My understanding is that the issues raised by the non-binding -1 are to be
taken as guidance for subsequent release lines and do not impact the
standing of this candidate.

Mike, is that view consistent with your intentions?

Thanks,
Nick


On Fri, Dec 8, 2017 at 9:00 PM, Nick Dimiduk  wrote:

> +1
>
> - verified tarballs vs public key on people.apache.org.
> - extracted bin tgz:
>   - inspect structure. look good.
>   - with jdk1.8.0_65:
> - run LoadTestTool against standalone bin tgz with FAST_DIFF block
> encoder and ROWCOL blooms. No issues, logs look good.
> - poked around webUI. looks good.
>   - load the site, browsed book.
> - extracted src tgz:
>   - inspect structure. look good.
>   - run LoadTestTool against standalone built from src tgz with FAST_DIFF
> block encoder and ROWCOL blooms. No issues, logs look good.
>   - poked around webUI. looks good.
> - ran the hbase-downstreamer project vs. the staged maven repository.
> tests pass.
>
> On Thu, Dec 7, 2017 at 1:44 PM, Ted Yu  wrote:
>
>> +1
>>
>> Checked sums and signatures: ok
>> Ran unit tests: passed
>> Started standalone cluster and did some basic operations
>>
>> On Thu, Dec 7, 2017 at 1:14 PM, Andrew Purtell 
>> wrote:
>>
>> > +1
>> >
>> > Checked sums and signatures: ok
>> > Checked compat report: ok
>> > RAT check passed: ok (7u80)
>> > Built from source: ok (7u80)
>> > Unit tests pass: ok (8u131)
>> > 1M row LTT: ok (8u131)
>> >
>> >
>> > On Thu, Dec 7, 2017 at 8:40 AM, Nick Dimiduk 
>> wrote:
>> >
>> > > No one has voted a binding -1 with actionable changes, so as far as
>> I'm
>> > > concerned this RC remains valid. If people need more time, we can
>> extend
>> > > this vote.
>> > >
>> > > Thanks,
>> > > Nick
>> > >
>> > > On Thu, Dec 7, 2017 at 8:07 AM, Ted Yu  wrote:
>> > >
>> > > > Nick:
>> > > > Originally you set tomorrow as deadline.
>> > > >
>> > > > Is there a new RC coming out (w.r.t. Mike's comment) ?
>> > > >
>> > > > Cheers
>> > > >
>> > > > On Mon, Dec 4, 2017 at 8:37 PM, Nick Dimiduk 
>> > > wrote:
>> > > >
>> > > > > Mike:
>> > > > >
>> > > > > > Do you plan to make a human-readable set of release notes in
>> > addition
>> > > > to
>> > > > > the list of JIRA issues resolved?
>> > > > >
>> > > > > Not as such. For all branch-1.1 releases, I've written up a little
>> > > > > human-friendly summary in the ANNOUNCE email. Basically,
>> expanding on
>> > > the
>> > > > > list of JIRA tickets I highlight in the RC notes to include their
>> > full
>> > > > > ticket summaries. I haven't followed the details of the branch-1.4
>> > > > release
>> > > > > line, so I'm not sure what additional information you might be
>> hoping
>> > > > for.
>> > > > >
>> > > > > > tar missing hbase-native-client (present in tag)
>> > > > >
>> > > > > That's been the case since rel/1.1.0. We as a community have
>> never
>> > > > shipped
>> > > > > a binary native client in this release line and we've never
>> claimed
>> > > that
>> > > > > the native sources packaged herein are ready for production
>> > > consumption.
>> > > > > They probably should have been dropped from the branch before
>> initial
>> > > > > release, but that was not done. I have no objection to dropping
>> them
>> > > > from a
>> > > > > branch-1.1 release; from the git log, I see no commit activity to
>> > that
>> > > > > module since Jan 2014. I don't see any of this as a blocker for
>> this
>> > > RC.
>> > > > >
>> > > > > > WARNING! HBase file layout needs to be upgraded ...
>> > > > >
>> > > > > When I test these RC's on a Mac, I explicitly set hbase.tmp.dir
>> to a
>> > > > > location specific to the candidate I've unpacked. This has the
>

Re: [VOTE] First release candidate for HBase 1.1.13 (RC0) is available

[Nick Dimiduk]

On Mon, Dec 11, 2017 at 8:20 AM, Mike Drob  wrote:

> Yea, this candidate is fine to promote from my perspective and given the
> other votes cast. Thanks for putting this together, Nick!
>

Mike,

In that case, would you mind formally upgrading your vote from a -1? I'd
like to remove any ambiguity that may remain. With that done, I can call
the VOTE.

Thanks,
Nick

On Sun, Dec 10, 2017 at 7:11 PM, Nick Dimiduk  wrote:
>
> > At close of the period, this VOTE has received 3x binding +1's, a
> > non-binding +1, and a non-binding -1, with no other votes cast.
> >
> > My understanding is that the issues raised by the non-binding -1 are to
> be
> > taken as guidance for subsequent release lines and do not impact the
> > standing of this candidate.
> >
> > Mike, is that view consistent with your intentions?
> >
> > Thanks,
> > Nick
> >
> >
> > On Fri, Dec 8, 2017 at 9:00 PM, Nick Dimiduk 
> wrote:
> >
> > > +1
> > >
> > > - verified tarballs vs public key on people.apache.org.
> > > - extracted bin tgz:
> > >   - inspect structure. look good.
> > >   - with jdk1.8.0_65:
> > > - run LoadTestTool against standalone bin tgz with FAST_DIFF block
> > > encoder and ROWCOL blooms. No issues, logs look good.
> > > - poked around webUI. looks good.
> > >   - load the site, browsed book.
> > > - extracted src tgz:
> > >   - inspect structure. look good.
> > >   - run LoadTestTool against standalone built from src tgz with
> FAST_DIFF
> > > block encoder and ROWCOL blooms. No issues, logs look good.
> > >   - poked around webUI. looks good.
> > > - ran the hbase-downstreamer project vs. the staged maven repository.
> > > tests pass.
> > >
> > > On Thu, Dec 7, 2017 at 1:44 PM, Ted Yu  wrote:
> > >
> > >> +1
> > >>
> > >> Checked sums and signatures: ok
> > >> Ran unit tests: passed
> > >> Started standalone cluster and did some basic operations
> > >>
> > >> On Thu, Dec 7, 2017 at 1:14 PM, Andrew Purtell 
> > >> wrote:
> > >>
> > >> > +1
> > >> >
> > >> > Checked sums and signatures: ok
> > >> > Checked compat report: ok
> > >> > RAT check passed: ok (7u80)
> > >> > Built from source: ok (7u80)
> > >> > Unit tests pass: ok (8u131)
> > >> > 1M row LTT: ok (8u131)
> > >> >
> > >> >
> > >> > On Thu, Dec 7, 2017 at 8:40 AM, Nick Dimiduk 
> > >> wrote:
> > >> >
> > >> > > No one has voted a binding -1 with actionable changes, so as far
> as
> > >> I'm
> > >> > > concerned this RC remains valid. If people need more time, we can
> > >> extend
> > >> > > this vote.
> > >> > >
> > >> > > Thanks,
> > >> > > Nick
> > >> > >
> > >> > > On Thu, Dec 7, 2017 at 8:07 AM, Ted Yu 
> wrote:
> > >> > >
> > >> > > > Nick:
> > >> > > > Originally you set tomorrow as deadline.
> > >> > > >
> > >> > > > Is there a new RC coming out (w.r.t. Mike's comment) ?
> > >> > > >
> > >> > > > Cheers
> > >> > > >
> > >> > > > On Mon, Dec 4, 2017 at 8:37 PM, Nick Dimiduk <
> ndimi...@apache.org
> > >
> > >> > > wrote:
> > >> > > >
> > >> > > > > Mike:
> > >> > > > >
> > >> > > > > > Do you plan to make a human-readable set of release notes in
> > >> > addition
> > >> > > > to
> > >> > > > > the list of JIRA issues resolved?
> > >> > > > >
> > >> > > > > Not as such. For all branch-1.1 releases, I've written up a
> > little
> > >> > > > > human-friendly summary in the ANNOUNCE email. Basically,
> > >> expanding on
> > >> > > the
> > >> > > > > list of JIRA tickets I highlight in the RC notes to include
> > their
> > >> > full
> > >> > > > > ticket summaries. I haven't followed the details of the
> > branch-1.4
> > >> > > > release
> > >> > > > > line, so I'm not sure what ad

[RESULT][VOTE] First release candidate for HBase 1.1.13 (RC0) is available

[Nick Dimiduk]

This VOTE has passed, with 3x binding +1's, a non-binding +1, and a
non-binding -0. Thank you to everyone who voted on this release, and who
has participated over the last 18-ish months on making branch-1.1 a
successful, viable release line.

I'll go about the finishing touches.

Thanks,
Nick

On Mon, Dec 11, 2017 at 11:21 AM, Mike Drob  wrote:

> Let's call it a -0. :)
>
> On Mon, Dec 11, 2017 at 1:14 PM, Nick Dimiduk  wrote:
>
> > On Mon, Dec 11, 2017 at 8:20 AM, Mike Drob  wrote:
> >
> > > Yea, this candidate is fine to promote from my perspective and given
> the
> > > other votes cast. Thanks for putting this together, Nick!
> > >
> >
> > Mike,
> >
> > In that case, would you mind formally upgrading your vote from a -1? I'd
> > like to remove any ambiguity that may remain. With that done, I can call
> > the VOTE.
> >
> > Thanks,
> > Nick
> >
> > On Sun, Dec 10, 2017 at 7:11 PM, Nick Dimiduk 
> wrote:
> > >
> > > > At close of the period, this VOTE has received 3x binding +1's, a
> > > > non-binding +1, and a non-binding -1, with no other votes cast.
> > > >
> > > > My understanding is that the issues raised by the non-binding -1 are
> to
> > > be
> > > > taken as guidance for subsequent release lines and do not impact the
> > > > standing of this candidate.
> > > >
> > > > Mike, is that view consistent with your intentions?
> > > >
> > > > Thanks,
> > > > Nick
> > > >
> > > >
> > > > On Fri, Dec 8, 2017 at 9:00 PM, Nick Dimiduk 
> > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > - verified tarballs vs public key on people.apache.org.
> > > > > - extracted bin tgz:
> > > > >   - inspect structure. look good.
> > > > >   - with jdk1.8.0_65:
> > > > > - run LoadTestTool against standalone bin tgz with FAST_DIFF
> > block
> > > > > encoder and ROWCOL blooms. No issues, logs look good.
> > > > > - poked around webUI. looks good.
> > > > >   - load the site, browsed book.
> > > > > - extracted src tgz:
> > > > >   - inspect structure. look good.
> > > > >   - run LoadTestTool against standalone built from src tgz with
> > > FAST_DIFF
> > > > > block encoder and ROWCOL blooms. No issues, logs look good.
> > > > >   - poked around webUI. looks good.
> > > > > - ran the hbase-downstreamer project vs. the staged maven
> repository.
> > > > > tests pass.
> > > > >
> > > > > On Thu, Dec 7, 2017 at 1:44 PM, Ted Yu 
> wrote:
> > > > >
> > > > >> +1
> > > > >>
> > > > >> Checked sums and signatures: ok
> > > > >> Ran unit tests: passed
> > > > >> Started standalone cluster and did some basic operations
> > > > >>
> > > > >> On Thu, Dec 7, 2017 at 1:14 PM, Andrew Purtell <
> apurt...@apache.org
> > >
> > > > >> wrote:
> > > > >>
> > > > >> > +1
> > > > >> >
> > > > >> > Checked sums and signatures: ok
> > > > >> > Checked compat report: ok
> > > > >> > RAT check passed: ok (7u80)
> > > > >> > Built from source: ok (7u80)
> > > > >> > Unit tests pass: ok (8u131)
> > > > >> > 1M row LTT: ok (8u131)
> > > > >> >
> > > > >> >
> > > > >> > On Thu, Dec 7, 2017 at 8:40 AM, Nick Dimiduk <
> ndimi...@apache.org
> > >
> > > > >> wrote:
> > > > >> >
> > > > >> > > No one has voted a binding -1 with actionable changes, so as
> far
> > > as
> > > > >> I'm
> > > > >> > > concerned this RC remains valid. If people need more time, we
> > can
> > > > >> extend
> > > > >> > > this vote.
> > > > >> > >
> > > > >> > > Thanks,
> > > > >> > > Nick
> > > > >> > >
> > > > >> > > On Thu, Dec 7, 2017 at 8:07 AM, Ted Yu 
> > > wrote:
> > > > >> > >
> > > > >> > > > Nick:
> > > > >>

[ANNOUNCE] Apache HBase 1.1.13 is now available for download

[Nick Dimiduk]

The HBase team is happy to announce the immediate availability of HBase
1.1.13! Download it from an Apache mirror near you,
http://www.apache.org/dyn/closer.lua/hbase/, or wire up through the maven
repo.

Apache HBase is an open-source, distributed, versioned, non-relational
database. Apache HBase gives you low latency random access to billions of
rows with millions of columns atop non-specialized hardware. To learn more
about HBase, see https://hbase.apache.org/.

!!! This is the final release from branch-1.1 !!!

HBase 1.1.13 is the thirteenth and final patch release in the HBase 1.1
line, continuing on the theme of bringing a stable, reliable database to
the Hadoop and NoSQL communities. This release includes over 40 resolved
issues since the 1.1.12 release; the majority of these changes are to build
tooling rather than the product itself. Notable product correctness fixes
include:

HBASE-18665 ReversedScannerCallable invokes getRegionLocations incorrectly
HBASE-19052 FixedFileTrailer should recognize CellComparatorImpl class in
branch-1.x

The full list of fixes included in this release is available at
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310753&version=12341346
and
and in the CHANGES.txt file included in the distribution.

Download through an ASF mirror near you:

https://www.apache.org/dyn/closer.lua/hbase/1.1.13

The relevant checksums files are available at:

https://www.apache.org/dist/hbase/1.1.13/hbase-1.1.13-src.tar.gz.mds
https://www.apache.org/dist/hbase/1.1.13/hbase-1.1.13-bin.tar.gz.mds

Project member signature keys can be found at

https://www.apache.org/dist/hbase/KEYS

PGP signatures are available at:

https://www.apache.org/dist/hbase/1.1.13/hbase-1.1.13-src.tar.gz.asc
https://www.apache.org/dist/hbase/1.1.13/hbase-1.1.13-bin.tar.gz.asc

For instructions on verifying ASF release downloads, please see

https://www.apache.org/dyn/closer.cgi#verify

Question, comments, and problems are always welcome at: dev@hbase.apache.org
.

Thanks to all the contributors who made this release possible, and to all
the contributors who made this release line a success!

Cheers,
The HBase Dev Team

EOL HBase 1.1

[Nick Dimiduk]

Hello,

This is for folks who haven't followed our discussions and aren't reading
closely the ANNOUNCE mail. The release line from branch-1.1 is now
concluded. 1.1.13 was the final release for that line. 1.2 has been our
stable release line for quite some time -- please upgrade!

Thank you again to all the professional and volunteer contributors who made
branch-1.1 possible.

Thanks,
Nick

Re: Assignment Manager and clock advance.

[Nick Dimiduk]

I don't think these assumptions are reliable. I've seen cases where
subsequent calls to currentTimeMillis() are non-incrementing on specific
Linux distributions. Taken in aggregate, the system clock makes progress,
but those aggregations are on the multi-second scale.

On Tue, Jan 2, 2018 at 4:37 PM Apekshit Sharma  wrote:

> Hi Sergey,
>
> Interesting test and find. Makes total sense too.
> However, in real world case, any put in meta table itself will take more
> than a ms, and then we have lot of Procedure framework and other logic in
> between meta accesses which would make this scenarios impossible.
> Specifically, there a lot of processing in between adding rows from
> CreateTableProcedure and trying to access it in children
> AssignProcedure(s).
>
> -- Apy
>
> On Tue, Jan 2, 2018 at 3:58 PM, Sergey Soldatov 
> wrote:
>
> > Hi,
> > Not sure whether we may consider that as a bug, but I found an
> interesting
> > dependency of AM2 on clock advancing. A simple operation such as create
> > table is unable to perform with the same current_time value:
> >
> > public void testCreateTable() throws IOException {
> >   EnvironmentEdgeManager.injectEdge(new EnvironmentEdge() {
> > volatile int curTime = 1000;
> >
> > @Override
> > public long currentTime() {
> >
> >   return curTime;
> > }
> >   });
> >   final TableName tableName = TableName.valueOf("test");
> >   TEST_UTIL.createTable(tableName, HConstants.CATALOG_FAMILY).close();
> > }
> >
> > and fails with a TableNotFound exception. The reason is that between
> > transitions we get table information from meta using Get with the
> exclusive
> > current timestamp. Could it be a potential problem (i.e. the system
> capable
> > to execute all that transition stuff in less than 1 ms)?
> >
> > Thanks,
> > Sergey
> >
>
>
>
> --
>
> -- Appy
>

Re: [DISCUSS] Purge hbase-archetypes?

[Nick Dimiduk]

That'd be a shame. This kind of thing makes getting started a lot easier
for folks. Maybe we move these to a separate repo? It's some crazy overhead
all things considered.

On Fri, Jan 12, 2018 at 9:25 PM Stack  wrote:

> Anyone using it? As far as I know it goes unsupported (anyone interested in
> this project?).
>
> Building a release takes two hours, one hour of which is archetype
> machinations, so its not my favorite module these times.
>
> Purge it from hbase?
>
> St.Ack
>

Re: Is HBaseTestingUtility part of public API?

[Nick Dimiduk]

I think downstream users pull this in for integration tests. We should
think about how we expect user applications to test their interactions with
HBase. While we're at it, we should consider publishing a test BOM pom to
reduce the guess-work. Stack's HBase Downstreamer is a good project to
shine a lens on this kind of support.

-n

On Fri, Jan 26, 2018 at 2:01 PM, Mike Drob  wrote:

> Can we make changes between releases? Do we know who else is using it?
>
> Mike
>

Re: [ANNOUNCE] HBase 0.98.5 is now available for download

[Nick Dimiduk]

Hi JM:

What if we convert the news bit into an RSS/Atom feed? Would that be
useful/interesting?

-n


On Tue, Aug 19, 2014 at 1:03 PM, Jean-Marc Spaggiari <
jean-m...@spaggiari.org> wrote:

> Hi Andrew,
>
> they are looking for a way to get as less emails as possible but get only
> the very important one like the releases announcements. So first idea was
> to register to the announce@apache where this is about 40 emails a month.
> But we are not there. They can for sure look into the website, but it's not
> as efficient as a push process like a mailing list.
>
> I can see other Hadoop ecosystem projects announcing on the mailing list
> for last digit releases like [ANNOUNCE] Apache Sqoop 1.4.5 released
> <
> http://mail-archives.apache.org/mod_mbox/www-announce/201408.mbox/ajax/%3CCAOvM-chFPXjW-1YWXFUfrGHE-bw%2BE%3DKN534k1UgH-CrprDJcYQ%40mail.gmail.com%3E
> >.
> I would say, might be nice if we do the same.
>
> JM
>
>
> 2014-08-19 15:31 GMT-04:00 Andrew Purtell :
>
> > Are they signed up on announce@apache? Or are they asking about
> > announcements through other means, like the hbase.apache.org front page?
> > We
> > can do that.
> >
> >
> > On Tue, Aug 19, 2014 at 12:28 PM, Jean-Marc Spaggiari <
> > jean-m...@spaggiari.org> wrote:
> >
> > > Should we? Some people asked me how to get informed about releases
> > without
> > > having to get all the user or dev emails...
> > >
> > >
> > > 2014-08-19 15:25 GMT-04:00 Andrew Purtell :
> > >
> > > > We haven't been doing that customarily, except for the .0 releases.
> > > >
> > > >
> > > > On Tue, Aug 19, 2014 at 9:57 AM, Jean-Marc Spaggiari <
> > > > jean-m...@spaggiari.org> wrote:
> > > >
> > > > > Should we also make announcements on  annou...@apache.org?
> > > > >
> > > > > JM
> > > > >
> > > > >
> > > > > 2014-08-13 15:10 GMT-04:00 Andrew Purtell :
> > > > >
> > > > > > ​​
> > > > > > Apache HBase 0.98.5 is now available for download.  Get it from
> an
> > > > Apache
> > > > > > mirror [1] or Maven repository.
> > > > > >
> > > > > > ​​
> > > > > > The list of changes in this release can be found in the release
> > notes
> > > > [2]
> > > > > > or following this announcement.
> > > > > >
> > > > > > ​​
> > > > > > Thanks to all who contributed to this release.
> > > > > >
> > > > > > ​​
> > > > > > Best,
> > > > > > ​​
> > > > > > The HBase Dev Team
> > > > > >
> > > > > > ​​
> > > > > > 1. http://www.apache.org/dyn/closer.cgi/hbase/
> > > > > > ​​
> > > > > > 2. http://s.apache.org/hIm
> > > > > > ​
> > > > > > ​HBASE-2217 VM OPTS for shell only
> > > > > > HBASE-3270 When we create the .version file, we should create it
> > in a
> > > > tmp
> > > > > > location and then move it into place
> > > > > > HBASE-7910 Dont use reflection for security
> > > > > > HBASE-11064 Odd behaviors of TableName for empty namespace
> > > > > > HBASE-11318 Classes in security subpackages missing
> > > @InterfaceAudience
> > > > > > annotations.
> > > > > > HBASE-11360 SnapshotFileCache causes too many cache refreshes
> > > > > > HBASE-11384 [Visibility Controller]Check for users covering
> > > > > authorizations
> > > > > > for every mutation
> > > > > > HBASE-11388 The order parameter is wrong when invoking the
> > > constructor
> > > > of
> > > > > > the ReplicationPeer In the method "getPeer" of the class
> > > > > > ReplicationPeersZKImpl
> > > > > > HBASE-11480 ClientScanner might not close the HConnection created
> > in
> > > > > > construction
> > > > > > HBASE-11516 Track time spent in executing coprocessors in each
> > > region.
> > > > > > HBASE-11518 doc update for how to create non-shared HConnection
> > > > > > HBASE-11534 Remove broken JAVA_HOME autodetection in
> > hbase-config.sh
> > > > > > HBASE-11537 Avoid synchronization on instances of ConcurrentMap
> > > > > > HBASE-11541 Wrong result when scaning meta with startRow
> > > > > > HBASE-11545 mapred.TableSnapshotInputFormat is missing
> > > > InterfaceAudience
> > > > > > annotation
> > > > > > HBASE-11551 BucketCache$WriterThread.run() doesn't handle
> > exceptions
> > > > > > correctly
> > > > > > HBASE-11554 Remove Reusable poolmap Rpc client type.
> > > > > > HBASE-11555 TableSnapshotRegionSplit should be public
> > > > > > HBASE-11557 Counter.class should always be added as dependencyJar
> > > > > > HBASE-11558 Caching set on Scan object gets lost when using
> > > > > > TableMapReduceUtil in 0.95+
> > > > > > HBASE-11559 Add dumping of DATA block usage to the BlockCache
> JSON
> > > > > report.
> > > > > > HBASE-11561 deprecate ImmutableBytesWritable.getSize and replace
> > with
> > > > > > getLength
> > > > > > HBASE-11565 Stale connection could stay for a while
> > > > > > HBASE-11566 make ExportSnapshot extendable by removing 'final'
> > > > > > HBASE-11579 CopyTable should check endtime value only if != 0
> > > > > > HBASE-11583 Refactoring out the configuration changes for
> enabling
> > > > > > VisibilityLabels in the unit tests.
> > > > > > HBASE-11586 HFile's HDFS op latency sampling code is 

Shout-out for Misty

[Nick Dimiduk]

Our docs are getting a lot of love lately, courtesy of one Misty
Stanley-Jones. As someone who joined this community by way of
documentation, I'd like to say: Thank you, Misty!

-n

Re: [VOTE] Which Orca representation?

[Nick Dimiduk]

[x] nkeywal's favorite


On Tue, Aug 19, 2014 at 6:33 PM, Andrew Purtell  wrote:

> [x] JMS orca
>
>
> On Tue, Aug 19, 2014 at 2:38 PM, Stack  wrote:
>
> > On the thread http://search-hadoop.com/m/DHED4uBtYz1, we voted an Orca
> as
> > our mascot.
> >
> > Below let us pick which Orca representation to use going forward.
> >
> > Intentionally, we are not voting on an 'hbase logo' + Orca combination.
> We
> > are justing voting on an Orca representation. Let putting together our
> > current logo and the chosen Orca image be a separate project (done by a
> > professional!). I think it ok voting on the image only because how they
> are
> > combined will vary with deployment context. We are voting on the image
> only
> > also because getting a set of 'hbase logo' and Orca combinations that are
> > of equal treatment to put under your noses is too much work.
> >
> > So, please vote on which Orca representation we should use going forward
> as
> > the Apache HBase mascot.  First review the options and then add your vote
> > in the section on the end.
> >
> > First up are the classics:
> >
> >
> https://issues.apache.org/jira/secure/attachment/12511525/apache%20hbase%20orca%20logo_Proof%203.pdf
> >  There are four on this page.  Number #1 is nkeywals's favorite.  Lets
> vote
> > on #1 and #2 only from this page (Where #2 is the black version of
> > nkeywal's favorite).
> >
> > This page has four from which to choose:
> > https://issues.apache.org/jira/secure/attachment/12648671/Apache_HBase
> > _Orca_Logo_round5.pdf The options are called out below as "Page N from
> > Apache_HBase_Orca_Logo_round5.pdf
> > <
> >
> https://issues.apache.org/jira/secure/attachment/12648671/Apache_HBase_Orca_Logo_round5.pdf
> > >",
> > etc.
> >
> > Enis used this one in his hbase 1.0 hbasecon talk:
> >
> >
> http://depositphotos.com/2900573/stock-illustration-killer-whale-tattoo.html
> >
> > Here is an image that just needs attribution arranged in a few ways by
> JMS:
> >
> >
> https://issues.apache.org/jira/secure/attachment/12662112/proposal_3_logo.png
> >
> >
> https://issues.apache.org/jira/secure/attachment/12662110/proposal_2_logo.png
> >
> >
> https://issues.apache.org/jira/secure/attachment/12661953/orca_free_vector_on_top_66percent_levelled.png
> >
> >
> https://issues.apache.org/jira/secure/attachment/12661954/orca_free_vector_some_selections.png
> >
> > Lets call this option the 'plus_orca'
> > https://issues.apache.org/jira/secure/attachment/12514291/plus_orca.png
> >
> > And finally, these two the miscellaneous orcas #1 and #2:
> >
> https://issues.apache.org/jira/secure/attachment/12514301/more_orcas2.png
> >
> > Fill in an 'x' into the box below for the one you want.
> >
> > [ ] nkeywal's favorite
> > [ ] Black version of nkeywal's favorite
> > [ ] Page 1 from Apache_HBase_Orca_Logo_round5.pdf
> > <
> >
> https://issues.apache.org/jira/secure/attachment/12648671/Apache_HBase_Orca_Logo_round5.pdf
> > >
> > [ ] Page 2 from Apache_HBase_Orca_Logo_round5.pdf
> > <
> >
> https://issues.apache.org/jira/secure/attachment/12648671/Apache_HBase_Orca_Logo_round5.pdf
> > >
> > [ ] Page 3 from Apache_HBase_Orca_Logo_round5.pdf
> > <
> >
> https://issues.apache.org/jira/secure/attachment/12648671/Apache_HBase_Orca_Logo_round5.pdf
> > >
> > [ ] Page 4 from Apache_HBase_Orca_Logo_round5.pdf
> > <
> >
> https://issues.apache.org/jira/secure/attachment/12648671/Apache_HBase_Orca_Logo_round5.pdf
> > >
> > [ ] Enis hbasecon talk
> > [ ] JMS orca
> > [ ] Plus orca
> > [ ] Miscellaneous #1
> > [ ] Miscellaneous #2
> > [ ] None of the above!
> >
>
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Re: 0.98-trunk build (pom) issue

[Nick Dimiduk]

The hadoop related profiles are for major versions (in branch-1 and
master). We have "hadoop-2.0" (current default) and "hadoop-3.0" (enabled
by specifying -Dhadoop.profile=3.0). I don't know why profiles are enabled
via property instead of by specifying the property (-P). These profiles
specify which hbase modules and dependency artifact (not version) should be
used.

The exact hadoop version is specified by a separate property. The
hadoop-2.0 profile check the property "hadoop-two.version". The hadoop-3.0
profile appears to use "hadoop.version" property.

So to build branch-1 vs hadoop-2.3.0, you would use "mvn
-Phadoop-two.version=2.3.0".

At least, that's what it looks like by reading the pom. Any patches to
clean these parts of the build are welcome ;)

-n


On Wed, Aug 20, 2014 at 11:55 AM, Jean-Marc Spaggiari <
jean-m...@spaggiari.org> wrote:

> " don't specify hadoop.profile unless != 2.0."
>
> So if we build against 2.3.0 should we specify -Phadoop.profile=2.3 ? Or we
> don't specify unless != 2.x?
>
> Thanks,
>
> JM
>
>
> 2014-08-14 14:03 GMT-04:00 Esteban Gutierrez :
>
> > What Andrew said. I'm building against 2.3.0 without any issue so far.
> >
> > cheers,
> > esteban.
> >
> >
> > --
> > Cloudera, Inc.
> >
> >
> >
> > On Thu, Aug 14, 2014 at 10:58 AM, Andrew Purtell 
> > wrote:
> >
> > > Oh. Sorry. Just remembered... to select the default profile you don't
> > > specify hadoop.profile. -Phadoop.profile=2.0 will cause issues, yes,
> > don't
> > > specify hadoop.profile unless != 2.0. And IIRC specifying a specific
> > Hadoop
> > > 2 version requires:
> > >
> > > -Dhadoop.version=2.x.x -Dhadoop-two.version=2.x.x
> > >
> > >
> > >
> > >
> > > On Thu, Aug 14, 2014 at 10:51 AM, Vladimir Rodionov <
> > > vladrodio...@gmail.com>
> > > wrote:
> > >
> > > > -Phadoop.version=2.2 worked fine to me. I was able to build package
> and
> > > > create eclipse workspace. I just checked dependencies and all hadoop
> > libs
> > > > are 2.2?
> > > >
> > > > -Vladimir Rodionov
> > > >
> > > >
> > > > On Thu, Aug 14, 2014 at 10:37 AM, Andrew Purtell <
> apurt...@apache.org>
> > > > wrote:
> > > >
> > > > > There is no hadoop.profile named "2.2". Use "2.0"
> > > > >
> > > > >
> > > > > On Thu, Aug 14, 2014 at 10:34 AM, Vladimir Rodionov <
> > > > > vladrodio...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Actually, -Phadoop.profile=2.2.
> > > > > >
> > > > > > -Vladimir Rodionov
> > > > > >
> > > > > >
> > > > > > On Thu, Aug 14, 2014 at 10:28 AM, Jean-Marc Spaggiari <
> > > > > > jean-m...@spaggiari.org> wrote:
> > > > > >
> > > > > > > You should try mvn clean package -DskipTests
> -Dhadoop.profile=2.0
> > > > > > >
> > > > > > > JM
> > > > > > >
> > > > > > >
> > > > > > > 2014-08-14 13:27 GMT-04:00 Vladimir Rodionov <
> > > vladrodio...@gmail.com
> > > > >:
> > > > > > >
> > > > > > > > I just synced my local 0.98-trunk and tried to build it:
> > > > > > > >
> > > > > > > > mvn clean package -DskipTests -Dhadoop.profile=2.2
> > > > > > > >
> > > > > > > >
> > > > > > > > [INFO] Scanning for projects...
> > > > > > > > [ERROR] The build could not read 1 project -> [Help 1]
> > > > > > > > [ERROR]
> > > > > > > > [ERROR]   The project org.apache.hbase:hbase:0.98.6-SNAPSHOT
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> (/Users/vrodionov/Development/hbase/vanila/hbase-0.98-trunk-patch-new/pom.xml)
> > > > > > > > has 2 errors
> > > > > > > > [ERROR]
> > > > 'dependencyManagement.dependencies.dependency.artifactId'
> > > > > > for
> > > > > > > > org.apache.hbase:${compat.module}:jar with value
> > > '${compat.module}'
> > > > > > does
> > > > > > > > not match a valid id pattern. @ line 997, column 21
> > > > > > > > [ERROR]
> > > > 'dependencyManagement.dependencies.dependency.artifactId'
> > > > > > for
> > > > > > > > org.apache.hbase:${compat.module}:test-jar with value
> > > > > > '${compat.module}'
> > > > > > > > does not match a valid id pattern. @ line 1002, column 21
> > > > > > > > [ERROR]
> > > > > > > > [ERROR] To see the full stack trace of the errors, re-run
> Maven
> > > > with
> > > > > > the
> > > > > > > -e
> > > > > > > > switch.
> > > > > > > > [ERROR] Re-run Maven using the -X switch to enable full debug
> > > > > logging.
> > > > > > > > [ERROR]
> > > > > > > > [ERROR] For more information about the errors and possible
> > > > solutions,
> > > > > > > > please read the following articles:
> > > > > > > > [ERROR] [Help 1]
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> > > > > > > >
> > > > > > > >
> > > > > > > > -Vladimir Rodionov
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > >
> > > > >- Andy
> > > > >
> > > > > Problems worthy of attack prove their worth by hitting back. - Piet
> > > Hein
> > > > > (via Tom White)
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Best reg

Re: 0.98-trunk build (pom) issue

[Nick Dimiduk]

On Wed, Aug 20, 2014 at 12:12 PM, Ted Yu  wrote:

> Minor correction: -Dhadoop-two.version=2.3.0 should be used.
>

Ha! Good catch Ted.

 On Wed, Aug 20, 2014 at 12:07 PM, Nick Dimiduk  wrote:
>
> > The hadoop related profiles are for major versions (in branch-1 and
> > master). We have "hadoop-2.0" (current default) and "hadoop-3.0" (enabled
> > by specifying -Dhadoop.profile=3.0). I don't know why profiles are
> enabled
> > via property instead of by specifying the property (-P). These profiles
> > specify which hbase modules and dependency artifact (not version) should
> be
> > used.
> >
> > The exact hadoop version is specified by a separate property. The
> > hadoop-2.0 profile check the property "hadoop-two.version". The
> hadoop-3.0
> > profile appears to use "hadoop.version" property.
> >
> > So to build branch-1 vs hadoop-2.3.0, you would use "mvn
> > -Phadoop-two.version=2.3.0".
> >
> > At least, that's what it looks like by reading the pom. Any patches to
> > clean these parts of the build are welcome ;)
> >
> > -n
> >
> >
> > On Wed, Aug 20, 2014 at 11:55 AM, Jean-Marc Spaggiari <
> > jean-m...@spaggiari.org> wrote:
> >
> > > " don't specify hadoop.profile unless != 2.0."
> > >
> > > So if we build against 2.3.0 should we specify -Phadoop.profile=2.3 ?
> Or
> > we
> > > don't specify unless != 2.x?
> > >
> > > Thanks,
> > >
> > > JM
> > >
> > >
> > > 2014-08-14 14:03 GMT-04:00 Esteban Gutierrez :
> > >
> > > > What Andrew said. I'm building against 2.3.0 without any issue so
> far.
> > > >
> > > > cheers,
> > > > esteban.
> > > >
> > > >
> > > > --
> > > > Cloudera, Inc.
> > > >
> > > >
> > > >
> > > > On Thu, Aug 14, 2014 at 10:58 AM, Andrew Purtell <
> apurt...@apache.org>
> > > > wrote:
> > > >
> > > > > Oh. Sorry. Just remembered... to select the default profile you
> don't
> > > > > specify hadoop.profile. -Phadoop.profile=2.0 will cause issues,
> yes,
> > > > don't
> > > > > specify hadoop.profile unless != 2.0. And IIRC specifying a
> specific
> > > > Hadoop
> > > > > 2 version requires:
> > > > >
> > > > > -Dhadoop.version=2.x.x -Dhadoop-two.version=2.x.x
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Aug 14, 2014 at 10:51 AM, Vladimir Rodionov <
> > > > > vladrodio...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > -Phadoop.version=2.2 worked fine to me. I was able to build
> package
> > > and
> > > > > > create eclipse workspace. I just checked dependencies and all
> > hadoop
> > > > libs
> > > > > > are 2.2?
> > > > > >
> > > > > > -Vladimir Rodionov
> > > > > >
> > > > > >
> > > > > > On Thu, Aug 14, 2014 at 10:37 AM, Andrew Purtell <
> > > apurt...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > There is no hadoop.profile named "2.2". Use "2.0"
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Aug 14, 2014 at 10:34 AM, Vladimir Rodionov <
> > > > > > > vladrodio...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Actually, -Phadoop.profile=2.2.
> > > > > > > >
> > > > > > > > -Vladimir Rodionov
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, Aug 14, 2014 at 10:28 AM, Jean-Marc Spaggiari <
> > > > > > > > jean-m...@spaggiari.org> wrote:
> > > > > > > >
> > > > > > > > > You should try mvn clean package -DskipTests
> > > -Dhadoop.profile=2.0
> > > > > > > > >
> > > > > > > > > JM
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2014-08-14 13:27 GMT-04:00 Vladimir Rodionov <

Re: 0.98-trunk build (pom) issue

[Nick Dimiduk]

On Wed, Aug 20, 2014 at 12:21 PM, Jean-Marc Spaggiari <
jean-m...@spaggiari.org> wrote:

> Ok. So -Dhadoop.two.version and -Dhadoop.version are exclusives, right?
> Even if it's not enforced, it's not logic to have the 2 together.
>

Some of this stuff is historical. This pom has evolved from the same one
that drove previous releases, where more gymnastics were required to build
more combinations of hbase and hadoop. Since we've dropped hadoop-1
support, could be things can be simplified a bit.

2014-08-20 15:12 GMT-04:00 Ted Yu :
>
> > Minor correction: -Dhadoop-two.version=2.3.0 should be used.
> >
> > Cheers
> >
> >
> > On Wed, Aug 20, 2014 at 12:07 PM, Nick Dimiduk 
> wrote:
> >
> > > The hadoop related profiles are for major versions (in branch-1 and
> > > master). We have "hadoop-2.0" (current default) and "hadoop-3.0"
> (enabled
> > > by specifying -Dhadoop.profile=3.0). I don't know why profiles are
> > enabled
> > > via property instead of by specifying the property (-P). These profiles
> > > specify which hbase modules and dependency artifact (not version)
> should
> > be
> > > used.
> > >
> > > The exact hadoop version is specified by a separate property. The
> > > hadoop-2.0 profile check the property "hadoop-two.version". The
> > hadoop-3.0
> > > profile appears to use "hadoop.version" property.
> > >
> > > So to build branch-1 vs hadoop-2.3.0, you would use "mvn
> > > -Phadoop-two.version=2.3.0".
> > >
> > > At least, that's what it looks like by reading the pom. Any patches to
> > > clean these parts of the build are welcome ;)
> > >
> > > -n
> > >
> > >
> > > On Wed, Aug 20, 2014 at 11:55 AM, Jean-Marc Spaggiari <
> > > jean-m...@spaggiari.org> wrote:
> > >
> > > > " don't specify hadoop.profile unless != 2.0."
> > > >
> > > > So if we build against 2.3.0 should we specify -Phadoop.profile=2.3 ?
> > Or
> > > we
> > > > don't specify unless != 2.x?
> > > >
> > > > Thanks,
> > > >
> > > > JM
> > > >
> > > >
> > > > 2014-08-14 14:03 GMT-04:00 Esteban Gutierrez :
> > > >
> > > > > What Andrew said. I'm building against 2.3.0 without any issue so
> > far.
> > > > >
> > > > > cheers,
> > > > > esteban.
> > > > >
> > > > >
> > > > > --
> > > > > Cloudera, Inc.
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Aug 14, 2014 at 10:58 AM, Andrew Purtell <
> > apurt...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Oh. Sorry. Just remembered... to select the default profile you
> > don't
> > > > > > specify hadoop.profile. -Phadoop.profile=2.0 will cause issues,
> > yes,
> > > > > don't
> > > > > > specify hadoop.profile unless != 2.0. And IIRC specifying a
> > specific
> > > > > Hadoop
> > > > > > 2 version requires:
> > > > > >
> > > > > > -Dhadoop.version=2.x.x -Dhadoop-two.version=2.x.x
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Aug 14, 2014 at 10:51 AM, Vladimir Rodionov <
> > > > > > vladrodio...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > -Phadoop.version=2.2 worked fine to me. I was able to build
> > package
> > > > and
> > > > > > > create eclipse workspace. I just checked dependencies and all
> > > hadoop
> > > > > libs
> > > > > > > are 2.2?
> > > > > > >
> > > > > > > -Vladimir Rodionov
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Aug 14, 2014 at 10:37 AM, Andrew Purtell <
> > > > apurt...@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > There is no hadoop.profile named "2.2". Use "2.0"
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, A

Compaction reports not right

[Nick Dimiduk]

Things are not quite right. This is a build of 0.98.4 + HBASE-10070 pieces.

Andrew, Lars, you guys were looking at this stuff recently, right?

http://people.apache.org/~ndimiduk/compactions.png

Rebuilding/publishing Book

[Nick Dimiduk]

Heya,

Would someone in the know mind publishing an updated copy of the book?
Better still, would you mind documenting how you do it... in the newly
published book ;)

We should share with the world Misty's latest work! (and I don't want to
re-explain salting again...)

-n

Re: Rebuilding/publishing Book

[Nick Dimiduk]

That's the missing link. I was looking under
http://hbase.apache.org/book.html#appendix_contributing_to_documentation

I'll give this a whirl. Any objections to rolling a site update this
afternoon?


On Thu, Aug 21, 2014 at 12:14 PM, Stack  wrote:

> See http://hbase.apache.org/book.html#hbase.org
>
> If you can't figure, let us know.
>
> St.Ack
>
>
>
> On Thu, Aug 21, 2014 at 12:10 PM, Nick Dimiduk  wrote:
>
> > Heya,
> >
> > Would someone in the know mind publishing an updated copy of the book?
> > Better still, would you mind documenting how you do it... in the newly
> > published book ;)
> >
> > We should share with the world Misty's latest work! (and I don't want to
> > re-explain salting again...)
> >
> > -n
> >
>

Re: Rebuilding/publishing Book

[Nick Dimiduk]

The full command fails for me with OOME during javadoc:aggregate,
despite MAVEN_OPTS="-Xmx3g -XX:MaxPermSize=512m". (the latter was suggested
here [0]). I think I've had this problem before. Any ideas?

$ mvn --version
Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
Maven home: /usr/share/maven
Java version: 1.7.0_25, vendor: Oracle Corporation
Java home:
/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.8.5", arch: "x86_64", family: "mac"

[0]:
http://mail-archives.apache.org/mod_mbox/maven-users/200710.mbox/%3C1C2EDF25917BA14D853DBFAB6CA91344E8676B@CPEXBE-EML15.kpnsp.local%3E



On Thu, Aug 21, 2014 at 12:41 PM, Nick Dimiduk  wrote:

> That's the missing link. I was looking under
> http://hbase.apache.org/book.html#appendix_contributing_to_documentation
>
> I'll give this a whirl. Any objections to rolling a site update this
> afternoon?
>
>
> On Thu, Aug 21, 2014 at 12:14 PM, Stack  wrote:
>
>> See http://hbase.apache.org/book.html#hbase.org
>>
>> If you can't figure, let us know.
>>
>> St.Ack
>>
>>
>>
>> On Thu, Aug 21, 2014 at 12:10 PM, Nick Dimiduk 
>> wrote:
>>
>> > Heya,
>> >
>> > Would someone in the know mind publishing an updated copy of the book?
>> > Better still, would you mind documenting how you do it... in the newly
>> > published book ;)
>> >
>> > We should share with the world Misty's latest work! (and I don't want to
>> > re-explain salting again...)
>> >
>> > -n
>> >
>>
>
>

Re: Rebuilding/publishing Book

[Nick Dimiduk]

I've upgraded java and now the full command documented in the book
completes for me.

I'm ready to republish the site whenever our docs folks require ;)

Thanks Stack, Andrew.


On Thu, Aug 21, 2014 at 3:34 PM, Andrew Purtell  wrote:

> >
> ​
> Could it be an OSX or Java or Maven version issue?
>
> -
> ​
>  Java version: 1.7.0_25, vendor: Oracle Corporation
> +
> ​
> Java version: 1.7.0_65, vendor: Oracle Corporation
>
> I've had issues with GC in 7u2x versions, so maybe that.
>
>
>
> On Thu, Aug 21, 2014 at 3:31 PM, Misty Stanley-Jones <
> mstanleyjo...@cloudera.com> wrote:
>
> > The command works for me locally:
> > $ MAVEN_OPTS=" -Xmx3g" mvn clean install -DskipTests javadoc:aggregate
> site
> >  site:stage -DstagingDirectory=/Users/misty/hbase.apache.org/trunk
> >
> > Here are my stats:
> > $ mvn --version
> > Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> > 2014-02-15T03:37:52+10:00)
> > Maven home: /opt/apache-maven-3.2.1
> > ​​
> > Java version: 1.7.0_65, vendor: Oracle Corporation
> > Java home:
> > /Library/Java/JavaVirtualMachines/jdk1.7.0_65.jdk/Contents/Home/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac"
> >
> > ​​
> > Could it be an OSX or Java or Maven version issue?
> >
> >
> > On Fri, Aug 22, 2014 at 6:46 AM, Nick Dimiduk 
> wrote:
> >
> > > The full command fails for me with OOME during javadoc:aggregate,
> > > despite MAVEN_OPTS="-Xmx3g -XX:MaxPermSize=512m". (the latter was
> > suggested
> > > here [0]). I think I've had this problem before. Any ideas?
> > >
> > > $ mvn --version
> > > Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
> > > Maven home: /usr/share/maven
> > ​​
> > >
> > ​​
> > ​​
> > Java version: 1.7.0_25, vendor: Oracle Corporation
> > > Java home:
> > > /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre
> > > Default locale: en_US, platform encoding: UTF-8
> > > OS name: "mac os x", version: "10.8.5", arch: "x86_64", family: "mac"
> > >
> > > [0]:
> > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/maven-users/200710.mbox/%3C1C2EDF25917BA14D853DBFAB6CA91344E8676B@CPEXBE-EML15.kpnsp.local%3E
> > >
> > >
> > >
> > > On Thu, Aug 21, 2014 at 12:41 PM, Nick Dimiduk 
> > wrote:
> > >
> > > > That's the missing link. I was looking under
> > > >
> > http://hbase.apache.org/book.html#appendix_contributing_to_documentation
> > > >
> > > > I'll give this a whirl. Any objections to rolling a site update this
> > > > afternoon?
> > > >
> > > >
> > > > On Thu, Aug 21, 2014 at 12:14 PM, Stack  wrote:
> > > >
> > > >> See http://hbase.apache.org/book.html#hbase.org
> > > >>
> > > >> If you can't figure, let us know.
> > > >>
> > > >> St.Ack
> > > >>
> > > >>
> > > >>
> > > >> On Thu, Aug 21, 2014 at 12:10 PM, Nick Dimiduk 
> > > >> wrote:
> > > >>
> > > >> > Heya,
> > > >> >
> > > >> > Would someone in the know mind publishing an updated copy of the
> > book?
> > > >> > Better still, would you mind documenting how you do it... in the
> > newly
> > > >> > published book ;)
> > > >> >
> > > >> > We should share with the world Misty's latest work! (and I don't
> > want
> > > to
> > > >> > re-explain salting again...)
> > > >> >
> > > >> > -n
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Re: Rebuilding/publishing Book

[Nick Dimiduk]

I rebuilt the site based on master/aada700 and published it here [0].
@Misty et al, care to browse through and make sure everything looks okay?
If so, I'll svn commit.

[0] http://people.apache.org/~ndimiduk/site/


On Mon, Aug 25, 2014 at 12:47 PM, Stack  wrote:

> On Sun, Aug 24, 2014 at 12:58 PM, Nick Dimiduk  wrote:
>
> > I've upgraded java and now the full command documented in the book
> > completes for me.
> >
> > I'm ready to republish the site whenever our docs folks require ;)
> >
>
> Try it Nick. Images in refguide are broke currently. Misty fixed them a
> while back.  Lets see if it takes.
> St.Ack
>

Re: Building the site - interesting problem

[Nick Dimiduk]

I think rsync is a good approach. It may take a bit, but we can work out
the correct --excludes list, so that 0.94, svn dot-files, and whatever else
are preserved. Did you explore this?

On Wed, Sep 10, 2014 at 8:58 PM, Misty Stanley-Jones <
mstanleyjo...@cloudera.com> wrote:

> Hi all,
>
> The way the site has been built for a while poses a problem I'm not sure
> how to solve. I'd like your input.
>
> Currently, the site is stored in a SVN repo. What happens is that we
> generate the site from the git repo sources and then copy the output over
> the top of the svn repo, svn add new files, and svn update.
>
> This causes some problems. The biggest problem is that if files become
> irrelevant (we remove a class or something, or remove a webpage, or
> something like that), there is actually no way to delete it from svn,
> because we don't start over with a fresh copy of the site each time.
>
> At first glance, it seems like an easy thing to fix. You could use an rsync
> job and just delete the ones that are not present in the generated source.
> But there are some things in there that are not generated anymore (such as
> 0.94 API docs) or at least not generated by running the site goal on
> master.
>
> So I need a way to figure out what files are truly stale and need to be
> deleted from svn, and which need to be left there. One strategy I thought
> of trying is to try to crawl the website starting from the front page and
> see all of the files that are reachable from there. The ones that are not,
> probably should be deleted.
>
> To that end, I am currently pulling down the site using wget, and I'll
> compare that to the contents in trunk and see what's different. But I'd
> like advice for what we can do about this in the future, since pulling down
> the site with wget takes ages.
>
> I'll update when I figure out more about it.
>
> Thanks,
> Misty
>

Re: build YCSB for hbase 0.98.5-hadoop2

[Nick Dimiduk]

Probably the HBase dependency jars are not correct. Was the version before
modification 0.94.x? As of 0.96, HBase is a multi-module build, no longer
shipped as a single jar. Can you pastebin the pom bits that reference
$hbase.version ?

-n

On Sunday, September 14, 2014, 牛兆捷  wrote:

> I just modify the hbase version to 0.98.5-hadoop2 and keep others
> unchanged.
>
> When I build it using "mvn clean package", it says the 0.98.5-hadoop2 can't
> be found in maven repo.
> Do I miss something?
>
>  2.2.1
> 0.98.5-hadoop2 0.7.0
>  7.1.0.CR1
> 2.1.1 1.0
>  2.9.0
> 1.0.1 2.0.0
>  0.81
> UTF-8
> 0.8.0 0.9.5.6
>  
>
> 2014-09-14 14:35 GMT+08:00 ramkrishna vasudevan <
> ramkrishna.s.vasude...@gmail.com >:
>
> > What is the problem you are facing?
> > https://github.com/ramkrish86/ycsb/tree/ycsb_visibility.  You can refer
> > the
> > ycsb pom here. This explains how we tried to build ycsb with 0.98.  May
> be
> > useful.
> > Incase you are missing something in the pom.
> > Regards
> > Ram
> >
> > On Sun, Sep 14, 2014 at 10:00 AM, Stack >
> wrote:
> >
> > > 0.98.5-hadoop2 has been pushed to mvn (see
> > > http://mvnrepository.com/search?q=hbase for example)  What is the
> issue
> > > you
> > > are seeing?
> > > St.Ack
> > >
> > > On Fri, Sep 12, 2014 at 7:29 PM, 牛兆捷  > wrote:
> > >
> > > > If I want to rebuild YCSB specific for hbase 0.98.5-hadoop2, what
> > should
> > > I
> > > > do?
> > > >
> > > > --
> > > > *Regards,*
> > > > *Zhaojie*
> > > >
> > >
> >
>
>
>
> --
> *Regards,*
> *Zhaojie*
>

Re: Anyone having problems committing code?

[Nick Dimiduk]

I had some issues last week, had to reset the password before each commit.
After talking to the Apache infra folks, I think it was because of an old
password in my ~/.m2/settings.xml. Apparently every time I invoked maven,
it attempted to authenticate, and eventually it locked the account. I
removed the offending stanza but I haven't tried since.

-n

On Wednesday, September 17, 2014, Jonathan Hsieh  wrote:

> Hey all,
>
> I was able to commit about 4 hours ago but the next patch I'm trying to
> commit has been failing with the no dav (bad password).  and haven't seen
> any other commits since then.
>
> is this just me or is it affecting anyone else?
>
> Thanks,
> Jon.
>
> --
> // Jonathan Hsieh (shay)
> // HBase Tech Lead, Software Engineer, Cloudera
> // j...@cloudera.com  // @jmhsieh
>

Re: A Chome extension for rendering patch on JIRA

[Nick Dimiduk]

Wow, this is slick!

On Thursday, October 16, 2014, Ted Yu  wrote:

> Verified that everything works well.
>
> Thanks for the fast turn around.
>
> On Thu, Oct 16, 2014 at 10:23 AM, David DENG  > wrote:
>
> > The new version should've solved this problem. Thanks for reporting.
> >
> > David
> >
> > On Wed, Oct 15, 2014 at 11:09 AM, Ted Yu  > wrote:
> >
> > > David:
> > > Thanks for the new feature.
> > >
> > > I found a little rendering bug. If you look at the following using your
> > > plugin:
> > >
> > >
> >
> https://issues.apache.org/jira/secure/attachment/12675067/HBASE-12267_v2.patch
> > >
> > > You would see that the 3rd line below (MultiTableOutputFormat.java):
> > > public void close(TaskAttemptContext context) throws IOException { -
> for
> > > (HTable table : tables.values()) { + for (Pair pair
> :
> > > tables.values()) {
> > >
> > > becomes:
> > > for (Pair pair : tables.values()) {
> > >
> > > On Tue, Oct 14, 2014 at 10:05 PM, David DENG  >
> > > wrote:
> > >
> > > > Version 1.5 has been submitted. Click on the icon to switch between
> > > > original and formatted.
> > > >
> > > > On Tue, Oct 14, 2014 at 6:43 AM, David DENG  >
> > > wrote:
> > > >
> > > > > I'll make clicks on the icon on toolbar switching between original
> > and
> > > > > formatted. Couldn't be later than this weekend.
> > > > >
> > > > > David
> > > > >
> > > > > On Mon, Oct 13, 2014 at 10:19 PM, tobe  >
> > wrote:
> > > > >
> > > > >> I could like to copy the address in Firefox to view the original
> > file
> > > or
> > > > >> just disable the plugin.
> > > > >>
> > > > >> On Tue, Oct 14, 2014 at 12:08 PM, Ted Yu  >
> > wrote:
> > > > >>
> > > > >> > Sometimes the reviewer may want to reference some particular
> diff
> > in
> > > > >> review
> > > > >> > comment.
> > > > >> >
> > > > >> > Is there a way to switch back to viewing the text of the patch ?
> > > > >> >
> > > > >> > I fully understand that you have other priorities.
> > > > >> >
> > > > >> > Cheers
> > > > >> >
> > > > >> > On Sat, Oct 11, 2014 at 9:37 PM, David DENG <
> > davidden...@gmail.com >
> > > > >> wrote:
> > > > >> >
> > > > >> > > Published a new version of the exteions:
> > > > >> > >
> > > > >> > > 1. An icon is shown right to the address bar. When viewing
> patch
> > > in
> > > > an
> > > > >> > > arbitrary url, click on the icon, it'll be rendered. This
> > support
> > > > >> cause
> > > > >> > the
> > > > >> > > extension needs a re-enabling when upgraded. (Sorry for the
> > > > >> re-enalbing)
> > > > >> > >
> > > > >> > > 2. Add an option page to set url patterns which are auto
> > rendered.
> > > > >> > Default
> > > > >> > > values are Apache jira patches (added [.]txt pattern)
> > > > >> > >
> > > > >> > > David
> > > > >> > >
> > > > >> > > On Fri, Oct 10, 2014 at 6:22 PM, Ted Yu  >
> > > > wrote:
> > > > >> > >
> > > > >> > > > Yes.
> > > > >> > > >
> > > > >> > > > See https://issues.apache.org/jira/browse/HBASE-12164
> > > > >> > > >
> > > > >> > > > On Fri, Oct 10, 2014 at 5:58 PM, David DENG <
> > > > davidden...@gmail.com >
> > > > >> > > wrote:
> > > > >> > > >
> > > > >> > > > > @Ted, people also submit patch with .txt extension?
> > > > >> > > > >
> > > > >> > > > > David
> > > > >> > > > >
> > > > >> > > > > On Fri, Oct 10, 2014 at 5:35 PM, Ted Yu <
> > yuzhih...@gmail.com >
> > > > >> wrote:
> > > > >> > > > >
> > > > >> > > > > > Interesting.
> > > > >> > > > > >
> > > > >> > > > > > Can you add the following to the recognized patterns ?
> > > > >> > > > > >
> > > > >> > > > > > https://issues.apache.org/jira/secure/attachment/*/*.
> > > > >> > > > > > <
> > https://issues.apache.org/jira/secure/attachment/*/*.patch
> > > > >txt
> > > > >> > > > > >
> > > > >> > > > > > On Fri, Oct 10, 2014 at 4:57 PM, David DENG <
> > > > >> davidden...@gmail.com 
> > > > >> > >
> > > > >> > > > > wrote:
> > > > >> > > > > >
> > > > >> > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://chrome.google.com/webstore/detail/git-patch-viewer/hkoggakcdopbgnaeeidcmopfekipkleg
> > > > >> > > > > > >
> > > > >> > > > > > > Go to one of the JIRA patch, the raw text will be
> > rendered
> > > > as
> > > > >> a
> > > > >> > > > > > Phabricator
> > > > >> > > > > > > like page (Like http://review.facebook.net/ ).
> > > > >> > > > > > > Recognized URL pattern:
> > > > >> > > > > > >
> > > https://issues.apache.org/jira/secure/attachment/*/*.patch
> > > > >> > > > > > >
> > > > >> > > > > > > Source code and bug report:
> > > > >> > > https://github.com/daviddengcn/patch-ext
> > > > >> > > > > > >
> > > > >> > > > > > > Have a try and enjoy!
> > > > >> > > > > > >
> > > > >> > > > > > > David
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Managed Connections and HBase 1.0

[Nick Dimiduk]

Yes, the concept of connection caching, aka, managed connections are going
away. See also HBASE-9117. I tried rebasing that monster patch a couple
weeks back and decided it wasn't worth it. If you're interested in tackling
this problem, I recommend biting off smaller chunks.

On Wed, Oct 22, 2014 at 6:00 PM, Solomon Duskis  wrote:

> I have a question about managed vs. unmanaged connections in HBase 1.0.
> The new ConnectionFactory implementation and the Connection interface don't
> seem to include the concept of managed connections for tables.  Are HTable
> managed connections going to be deprecated?
>
> -Solomon Duskis
>

Re: Reworking the use of log levels

[Nick Dimiduk]

We have the ability to alter log levels at runtime. This would allow an
operator to temporarily increase log level for afflicted components, even
in production. Doing this on a server-by-server basis should have minimal
impact on overall cluster performance. Maybe this needs to be better
documented? Maybe we need a script that makes this easier, or could be
managed via a new shell command?

On Saturday, October 25, 2014, Andrew Purtell  wrote:

> ​
> On Sat, Oct 25, 2014 at 6:34 AM, Sean Busbey  > wrote:
>
> > Even if debug is disabled in production, it could be enabled on a
> > non-production system for reproducing the problem, no?
> >
>
> ​In my experience, often enough, no.​
>
> I do hear the complaint that Hadoop ecosystem projects are quite operator
> unfriendly because error messages most often come in the form of a
> stacktrace. It's a totally valid point. I think we could certainly improve
> the exception message printed ahead of the stacktrace in a large number of
> cases.
>
>
>
> On Sat, Oct 25, 2014 at 6:34 AM, Sean Busbey  > wrote:
>
> > Even if debug is disabled in production, it could be enabled on a
> > non-production system for reproducing the problem, no?
> >
> > --
> > Sean
> > On Oct 25, 2014 7:11 AM, "Qiang Tian" >
> wrote:
> >
> > > perhaps case by case is better. stacktrace is one of most important
> > problem
> > > determination methods.  debug is mostly disabled in production, we may
> > lose
> > > important clues.
> > >
> > >
> > > On Sat, Oct 25, 2014 at 1:14 PM, Sean Busbey  >
> > wrote:
> > >
> > > > Hi!
> > > >
> > > > Right now we have many failure paths where we send stack traces to
> log
> > > > files at ERROR / WARN. In an effort to make things easier to operate,
> > I'd
> > > > like to propose we move towards:
> > > >
> > > > * INFO/WARN/ERROR : description of failure and if possible an action
> an
> > > > operator could take to fix/diagnose
> > > > * DEBUG : information needed to handle failures that require
> developer
> > > > action, i.e. stack traces
> > > >
> > > > I figure this can go as one or more subtasks off of HBASE-12341, but
> > > wanted
> > > > to float things here before I get started.
> > > >
> > > > --
> > > > Sean
> > > >
> > >
> >
>
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Unable to fetch?

[Nick Dimiduk]

Is anyone else seeing this? Seems like there was a forced push to the
hbase-11339 branch.

$ git --no-pager fetch apache-rw
error: Ref refs/remotes/apache-rw/hbase-11339 is at
8a8b7de760a33c8195e287975d5b4a337d71b1fa but expected
aa523164e825567d93eb0b2a191955ca195ea242
>From https://git-wip-us.apache.org/repos/asf/hbase
 ! aa52316..e5a1b86  hbase-11339 -> apache-rw/hbase-11339  (unable to
update local ref)
git exited abnormally with code 1.

Re: Unable to fetch?

[Nick Dimiduk]

Looks like there are two branches for HBASE-11339; one is upper case and
the other is lower case. This is breaking for me because the Mac filesystem
is not case sensitive. It appears the capitalized version was pushed
unintentionally via this commit [0]. Would the folks working on this
feature please delete one of the two branches and fix the situation for us
unfortunate mac users?

Thanks,
Nick

[0]:
https://github.com/apache/hbase/commit/8a8b7de760a33c8195e287975d5b4a337d71b1fa

On Fri, Oct 31, 2014 at 5:56 PM, Ted Yu  wrote:

> I got this earlier today.
>
> I had to re-clone my git workspace.
>
> Cheers
>
> On Oct 31, 2014, at 5:54 PM, Nick Dimiduk  wrote:
>
> > Is anyone else seeing this? Seems like there was a forced push to the
> > hbase-11339 branch.
> >
> > $ git --no-pager fetch apache-rw
> > error: Ref refs/remotes/apache-rw/hbase-11339 is at
> > 8a8b7de760a33c8195e287975d5b4a337d71b1fa but expected
> > aa523164e825567d93eb0b2a191955ca195ea242
> > From https://git-wip-us.apache.org/repos/asf/hbase
> > ! aa52316..e5a1b86  hbase-11339 -> apache-rw/hbase-11339  (unable to
> > update local ref)
> > git exited abnormally with code 1.
>

Re: Unable to fetch?

[Nick Dimiduk]

Both the branches contained identical history. Tried to delete the
uppercase branch with the following command.

$ git push apache-rw --delete HBASE-11339
To https://git-wip-us.apache.org/repos/asf/hbase.git
 - [deleted] HBASE-11339

Says it worked, but I'm still having trouble fetching.



On Mon, Nov 3, 2014 at 3:17 PM, Stack  wrote:

> How did you do that Andrew?
>
> I looked at the two branches and they seem the same if I compare on a
> case-sensitive system (git log --oneline|head -100 ...) or if I look over
> on github:
>
> https://github.com/apache/hbase/commits/hbase-11339
> https://github.com/apache/hbase/commits/HBASE-11339
>
> I tried to delete the upper case HBASE-11339 branch but I don't seem to be
> able to:
>
> [stack@c2020 hbase.git.clean]$ git push origin :HBASE-11339
> error: no DAV locking support on
> https://git-wip-us.apache.org/repos/asf/hbase.git/
> fatal: git-http-push failed
>
> A search turns up: https://git-wip-us.apache.org/docs/common-errors.html
>
> but I'm already on https.
>
> Unless anyone else has ideas, I'll file INFRA ticket and ask them delete
> them delete the upper-case HBASE-11339  branch.
>
> Would appreciate those working on this stuff shouting if there is
> differences between the branches.
>
> Jon is on vacation so I'm game for helping out here.
>
> St.Ack
>
>
> On Mon, Nov 3, 2014 at 10:19 AM, Andrew Purtell 
> wrote:
>
> > This isn't just an annoyance. Clearly active dev is happening on
> > "hbase-11339", last commit:
> >
> > commit e5a1b86dbad650f9740eb24a7f544c4a51f05654
> >
> > Author: Jonathan M Hsieh 
> >
> > Date:   Thu Oct 30 06:50:13 2014 -0700
> >
> >
> > HBASE-11683 Metrics for MOB (Jingcheng Du)
> >
> >
> > ​While on "HBASE-11339" it's ​
> >
> > commit 8a8b7de760a33c8195e287975d5b4a337d71b1fa
> >
> > Author: Ramkrishna 
> >
> > Date:   Fri Oct 31 15:43:58 2014 +0530
> >
> >
> > HBASE-12392 Incorrect implementation of
> >
> > CompactionRequest.isRetainDeleteMarkers(Jingcheng Du)
> >
> >
> > and this commit, HBASE-12392, is missing on "hbase-11339", so whatever it
> > is supposed to fix isn't fixed there.
> >
> > We need for someone working on MOB to commit HBASE-12392 into
> "hbase-11339"
> > and then drop the "HBASE-11339" branch. Thanks!
> >
> > ​
> >
> > On Fri, Oct 31, 2014 at 6:04 PM, Nick Dimiduk 
> wrote:
> >
> > > Looks like there are two branches for HBASE-11339; one is upper case
> and
> > > the other is lower case. This is breaking for me because the Mac
> > filesystem
> > > is not case sensitive. It appears the capitalized version was pushed
> > > unintentionally via this commit [0]. Would the folks working on this
> > > feature please delete one of the two branches and fix the situation for
> > us
> > > unfortunate mac users?
> > >
> > > Thanks,
> > > Nick
> > >
> > > [0]:
> > >
> > >
> >
> https://github.com/apache/hbase/commit/8a8b7de760a33c8195e287975d5b4a337d71b1fa
> > >
> > > On Fri, Oct 31, 2014 at 5:56 PM, Ted Yu  wrote:
> > >
> > > > I got this earlier today.
> > > >
> > > > I had to re-clone my git workspace.
> > > >
> > > > Cheers
> > > >
> > > > On Oct 31, 2014, at 5:54 PM, Nick Dimiduk 
> wrote:
> > > >
> > > > > Is anyone else seeing this? Seems like there was a forced push to
> the
> > > > > hbase-11339 branch.
> > > > >
> > > > > $ git --no-pager fetch apache-rw
> > > > > error: Ref refs/remotes/apache-rw/hbase-11339 is at
> > > > > 8a8b7de760a33c8195e287975d5b4a337d71b1fa but expected
> > > > > aa523164e825567d93eb0b2a191955ca195ea242
> > > > > From https://git-wip-us.apache.org/repos/asf/hbase
> > > > > ! aa52316..e5a1b86  hbase-11339 -> apache-rw/hbase-11339  (unable
> to
> > > > > update local ref)
> > > > > git exited abnormally with code 1.
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >- Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>

Re: Unable to fetch?

[Nick Dimiduk]

I take that back, it did work. The failure was coming from the
git.apache.org/hbase.git mirror, which hasn't propagated the delete yet.

On Mon, Nov 3, 2014 at 3:25 PM, Nick Dimiduk  wrote:

> Both the branches contained identical history. Tried to delete the
> uppercase branch with the following command.
>
> $ git push apache-rw --delete HBASE-11339
> To https://git-wip-us.apache.org/repos/asf/hbase.git
>  - [deleted] HBASE-11339
>
> Says it worked, but I'm still having trouble fetching.
>
>
>
> On Mon, Nov 3, 2014 at 3:17 PM, Stack  wrote:
>
>> How did you do that Andrew?
>>
>> I looked at the two branches and they seem the same if I compare on a
>> case-sensitive system (git log --oneline|head -100 ...) or if I look over
>> on github:
>>
>> https://github.com/apache/hbase/commits/hbase-11339
>> https://github.com/apache/hbase/commits/HBASE-11339
>>
>> I tried to delete the upper case HBASE-11339 branch but I don't seem to be
>> able to:
>>
>> [stack@c2020 hbase.git.clean]$ git push origin :HBASE-11339
>> error: no DAV locking support on
>> https://git-wip-us.apache.org/repos/asf/hbase.git/
>> fatal: git-http-push failed
>>
>> A search turns up: https://git-wip-us.apache.org/docs/common-errors.html
>>
>> but I'm already on https.
>>
>> Unless anyone else has ideas, I'll file INFRA ticket and ask them delete
>> them delete the upper-case HBASE-11339  branch.
>>
>> Would appreciate those working on this stuff shouting if there is
>> differences between the branches.
>>
>> Jon is on vacation so I'm game for helping out here.
>>
>> St.Ack
>>
>>
>> On Mon, Nov 3, 2014 at 10:19 AM, Andrew Purtell 
>> wrote:
>>
>> > This isn't just an annoyance. Clearly active dev is happening on
>> > "hbase-11339", last commit:
>> >
>> > commit e5a1b86dbad650f9740eb24a7f544c4a51f05654
>> >
>> > Author: Jonathan M Hsieh 
>> >
>> > Date:   Thu Oct 30 06:50:13 2014 -0700
>> >
>> >
>> > HBASE-11683 Metrics for MOB (Jingcheng Du)
>> >
>> >
>> > ​While on "HBASE-11339" it's ​
>> >
>> > commit 8a8b7de760a33c8195e287975d5b4a337d71b1fa
>> >
>> > Author: Ramkrishna 
>> >
>> > Date:   Fri Oct 31 15:43:58 2014 +0530
>> >
>> >
>> > HBASE-12392 Incorrect implementation of
>> >
>> > CompactionRequest.isRetainDeleteMarkers(Jingcheng Du)
>> >
>> >
>> > and this commit, HBASE-12392, is missing on "hbase-11339", so whatever
>> it
>> > is supposed to fix isn't fixed there.
>> >
>> > We need for someone working on MOB to commit HBASE-12392 into
>> "hbase-11339"
>> > and then drop the "HBASE-11339" branch. Thanks!
>> >
>> > ​
>> >
>> > On Fri, Oct 31, 2014 at 6:04 PM, Nick Dimiduk 
>> wrote:
>> >
>> > > Looks like there are two branches for HBASE-11339; one is upper case
>> and
>> > > the other is lower case. This is breaking for me because the Mac
>> > filesystem
>> > > is not case sensitive. It appears the capitalized version was pushed
>> > > unintentionally via this commit [0]. Would the folks working on this
>> > > feature please delete one of the two branches and fix the situation
>> for
>> > us
>> > > unfortunate mac users?
>> > >
>> > > Thanks,
>> > > Nick
>> > >
>> > > [0]:
>> > >
>> > >
>> >
>> https://github.com/apache/hbase/commit/8a8b7de760a33c8195e287975d5b4a337d71b1fa
>> > >
>> > > On Fri, Oct 31, 2014 at 5:56 PM, Ted Yu  wrote:
>> > >
>> > > > I got this earlier today.
>> > > >
>> > > > I had to re-clone my git workspace.
>> > > >
>> > > > Cheers
>> > > >
>> > > > On Oct 31, 2014, at 5:54 PM, Nick Dimiduk 
>> wrote:
>> > > >
>> > > > > Is anyone else seeing this? Seems like there was a forced push to
>> the
>> > > > > hbase-11339 branch.
>> > > > >
>> > > > > $ git --no-pager fetch apache-rw
>> > > > > error: Ref refs/remotes/apache-rw/hbase-11339 is at
>> > > > > 8a8b7de760a33c8195e287975d5b4a337d71b1fa but expected
>> > > > > aa523164e825567d93eb0b2a191955ca195ea242
>> > > > > From https://git-wip-us.apache.org/repos/asf/hbase
>> > > > > ! aa52316..e5a1b86  hbase-11339 -> apache-rw/hbase-11339  (unable
>> to
>> > > > > update local ref)
>> > > > > git exited abnormally with code 1.
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Best regards,
>> >
>> >- Andy
>> >
>> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> > (via Tom White)
>> >
>>
>
>

Re: KeyValue#createFirstOnRow() removed in hbase branch-1

[Nick Dimiduk]

+dev@hbase

On Wednesday, November 5, 2014, Anoop John  wrote:

> I see Phoenix using this API in many places..  So how about add it back in
> branch-1 with deprecation and remove from trunk(?)  Might be some other
> users also have used it. Deprecate in one major version and remove in next
> major version seems better.
>
> -Anoop-
>
> On Thu, Nov 6, 2014 at 12:06 AM, Ted Yu  > wrote:
>
> > Hi,
> > In hbase branch-1, KeyValue.createFirstOnRow() doesn't
> > exist. KeyValueUtil.createFirstOnRow() replaces that method.
> >
> > I want to get opinion on how Phoenix should deal with such API
> > compatibility issue now that hbase 1.0 release gets closer.
> >
> > Cheers
> >
>

Table#setAutoFlushTo

[Nick Dimiduk]

Heya,

Do we want to change this method name in the new Table interface to just
setAutoFlush? Will this be confusing for folks migrating from the
HTableInterface methods?

Would be good to make a decision on this (and any other Client API changes)
before 1.0.

-n

Re: Table#setAutoFlushTo

[Nick Dimiduk]

Also, #incrementColumnValue seems like it's "tacked on". It appears to be a
subset of functionality provided by #increment. Why do we provide this
interface but not an equivalent #appendColumnValue ?

Rename #mutateRow to just #mutate ? This would make mutate/checkAndMutate
consistent with put/checkAndPut and delete/checkAndDelete.

Do we want to drop the @deprecated methods from this interface as well, or
is that put off for 2.0 ?

On Thu, Nov 20, 2014 at 11:29 AM, Nick Dimiduk  wrote:

> Heya,
>
> Do we want to change this method name in the new Table interface to just
> setAutoFlush? Will this be confusing for folks migrating from the
> HTableInterface methods?
>
> Would be good to make a decision on this (and any other Client API
> changes) before 1.0.
>
> -n
>

Re: Replication terminology "master-master"

[Nick Dimiduk]

I guess "multi-master" is the more common term for this kind of replication.

On Tue, Nov 25, 2014 at 11:05 AM, Demai Ni  wrote:

> Agree with you guys. I also experienced difficulty to explain about
> Master-Master and  cyclical to my users before, until I began to talk about
> M-S only as building-block, which can be applied as one please.
>
> Just like to chime in another point, maybe the document should emphasize
> that the Master or Slave term is from *the perspective of
> 'table:columnFamly'*. It is often confused when using term as
> 'Master-cluster' or 'Slave-Cluster' as if the cluster as a whole is a
> Master/Slave. Unless the clusters are setup strictly as one-way
> replication. the Cluster often serves for both roles.
>
> Demai
>
> On Tue, Nov 25, 2014 at 9:21 AM, Andrew Purtell 
> wrote:
>
> >
> > > On Nov 25, 2014, at 11:09 AM, Jean-Daniel Cryans 
> > wrote:
> > >
> > > "A master can be
> > > slave too, and a slave a master, and cycles are allowed" since with
> just
> > > that you can build everything else.
> >
> > +1
> >
> >
> >
> > > On Nov 25, 2014, at 11:09 AM, Jean-Daniel Cryans 
> > wrote:
> > >
> > >> On Mon, Nov 24, 2014 at 8:29 PM, lars hofhansl 
> > wrote:
> > >>
> > >> Hmm... From that angle all we really have is master-slave replication,
> > >> without limit as how it can be setup.A master can be slave too, and a
> > slave
> > >> a master, and cycles are allowed.
> > >> I find "cyclical replication" more confusing than "master-master"
> > >> (although it's true that master-master is strictly a subset of
> cyclical
> > -
> > >> just a cycle of two).
> > >
> > > I agree with that.
> > >
> > >
> > >> We might want to scrap all the terms and just state (hopefully a bit
> > >> nicer) what I tried to say in the first two sentences above.
> > >
> > > One thing about "master-master" is that some audiences will get it
> right
> > > away, for example folks coming from the MySQL world, but maybe we want
> to
> > > skip using it in our doc and just say what you wrote above "A master
> can
> > be
> > > slave too, and a slave a master, and cycles are allowed" since with
> just
> > > that you can build everything else.
> > >
> > >
> > >> -- Lars
> > >>
> > >>  From: Misty Stanley-Jones 
> > >> To: dev@hbase.apache.org
> > >> Sent: Monday, November 24, 2014 7:26 PM
> > >> Subject: Replication terminology "master-master"
> > >>
> > >> Hi all,
> > >>
> > >> I think "master-master" is a term that should be re-thought. It is not
> > >> really a "type" of replication, but refers to a characteristic of  a
> > >> cluster, specifically a cluster which participates in multiple
> clusters
> > >> with different roles -- it is a slave in one cluster and a master in
> > >> another cluster. I think with the current terminology, people confuse
> it
> > >> with "cyclical" replication, in which two clusters replicate to each
> > other,
> > >> and eventually each has all the data from both.
> > >>
> > >> Since master-master in this sense is really not a type of
> replication, I
> > >> think we should just scrap it. You can have master-slave replication
> or
> > >> cyclical replication, or a combination. With master-slave
> replication, a
> > >> cluster can fulfill both roles at the same time, as long as it is in
> > >> different clusters. This is easy to understand as a sort of recursive
> > >> cascade.
> > >>
> > >> Am I explaining it right, and what do you guys think about changing
> our
> > >> terminology?
> > >>
> > >> Thanks,
> > >> Misty
> > >>
> > >>
> > >>
> > >>
> >
>

A face-lift for 1.0

[Nick Dimiduk]

Heya,

In mind of the new release, I was thinking we should clean up our act a
little bit in regard to hbase.apache.org and our book. Just because the
project started in 2007 doesn't mean we need a site that looks like it's
from 2007. Phoenix's site looks great in this regard.

For the home page, I was thinking of converting it over to bootstrap [0] so
that it'll be easier to pick up theme, either on of our own or something
pre-canned [1]. I'm no web designer, but the idea is this would make it
easier for someone who is to help us out.

For the book, I just want to skin it -- no intention of changing docbook
part (such a decision I'll leave up to Misty). I'm less sure on this
project, but Riak's docs are a nice inspiration.

What do you think? Do we know any web designers who can help out with the
CSS?

-n

[0]: http://getbootstrap.com
[1]: https://wrapbootstrap.com/
[2]: http://docs.basho.com/riak/latest/

Re: Please welcome our latest committer, Sean Busbey

[Nick Dimiduk]

Nice work Sean, congratulations!

On Thu, Dec 4, 2014 at 12:10 PM, Stack  wrote:

> Sean has been doing excellent work around these environs. Your PMC made him
> a committer in recognition.  Welcome Sean!
>
> St.Ack
>

Re: ByteBuffer Backed Cell - New APIs (HBASE-12358)

[Nick Dimiduk]

>From the perspective of API going forward, I prefer (2). BB already allows
for encapsulating a sequence if bytes in a single object, so why
re-implement that? I suspect you'll want to return slices to the caller
anyway, because you don't want them messing with the backing store's position,
limit, etc state.

On Friday, December 5, 2014, Jonathan Hsieh  wrote:

> I think of it from a compatibility point of view - each method has its own
> semantics and the semantics should not morph between versions.
>
> With the repurposing the old apis approach, someone who ports to the new
> version without porting to the api will likely run into some nasty
> surprises.  Worse yet, they'd need to modify their code and understand the
> details of what the semantics changes are.
>
> Having completely new apis makes it easier to see when deprecated
> behavior/methods are removed and doesn't require code inspection to verify.
> (can rely on compiler warnings)  Also, old code won't be broken (just less
> efficient).
>
> Jon.
>
>
>
> On Thu, Dec 4, 2014 at 10:41 PM, ramkrishna vasudevan <
> ramkrishna.s.vasude...@gmail.com > wrote:
>
> > We thought about this suggestion too but this comes with a lot of more
> > confusion (?) - what do you think?
> > Adding new APIs but similar in behaviour could lead to lot more
> confusion?
> > Internally it is more easy.
> >
> >
> > On Fri, Dec 5, 2014 at 11:10 AM, Jonathan Hsieh  > wrote:
> >
> > > Ram,
> > >
> > > Can we essentially do both by creating the new getXxBuffer, and then
> also
> > > creating new offset and len apis -- getXxx(Bb|Buffer|Buf|B)Offset and
> > > getXxx(Bb|Buffer|Buf|B)Length?
> > >
> > > The old getXxxArray could use the old getXxxOffset and getXxxLength
> > calls.
> > > Also we'd deprecate all of these and provide an sliced and diced
> version
> > > that would have offset always 0.
> > >
> > > This way we wouldn't conflate the Bb and byte[] offsets and lengths.
> > Also
> > > we could behind the scenes convert Bbs to byte[] arrays and convert
> > > byte[]'s in to Bbs while maintaining the same interface.
> > >
> > > Jon.
> > >
> > >
> > >
> > > On Thu, Dec 4, 2014 at 7:24 PM, ramkrishna vasudevan <
> > > ramkrishna.s.vasude...@gmail.com > wrote:
> > >
> > > > Hi Devs
> > > >
> > > > This write up is to provide a brief idea  on why we need a BB backed
> > cell
> > > > and what are the items that we need to take care before introducing
> new
> > > > APIs in Cell that are BB backed.
> > > >
> > > > Pls refer to https://issues.apache.org/jira/browse/HBASE-12358 also
> > and
> > > > its
> > > > parent JIRA https://issues.apache.org/jira/browse/HBASE-11425 for
> the
> > > > history.
> > > >
> > > > Coming back to the discussion on new APIs, this discussion is based
> on
> > > > supporting BB in the read path (write path is not targeted now) so
> that
> > > we
> > > > could work with offheap BBs also. This would avoid copying of data
> from
> > > > BlockCache to the read path ByteBuffer.
> > > >
> > > > Assume we will be working with BBs in the read path, We will need to
> > > >  introduce *getXXXBuffer() *APIs and also *hasArray()* in Cell itself
> > > > directly.
> > > > If we try to extend the cell or create a new Cell then *everywhere we
> > > need
> > > > to do instanceOf check or do type conversion *and that is why adding
> > new
> > > > APIs to Cell interface itself makes sense.
> > > >
> > > > Plan is to use this *getXXXBuffer()* API through out the read path
> > > *instead
> > > > of getXXXArray()*.
> > > >
> > > > Now there are two ways to use it
> > > >
> > > > 1) Use getXXXBuffer() along with getXXXOffset(), getXXXLength() like
> > how
> > > we
> > > > use now for getXXXArray() APIs with the offset and length. Doing so
> > would
> > > > ensure that every where in the filters and CP one has to just replace
> > the
> > > > getXXXArray() with getXXXBuffer() and continue to use getXXXOffset()
> > and
> > > > getXXXLength(). We would do some wrapping of the byte[] with a BB
> > incase
> > > of
> > > > KeyValue type of cells so that getXXXBuffer along with offset and
> > length
> > > > holds true everywhere. Note that here if hasArray is true(for KV
> case)
> > > then
> > > > getXXXArray() would also work.
> > > >
> > > > 2)The other way of using this is that use only getXXXBuffer() API and
> > > > ensure that the BB is always duplicated/sliced and only the portion
> of
> > > the
> > > > total BB is returned which represents the individual component of the
> > > Cell.
> > > > In this case there is no use of getXXXOffset() (as it is going to be
> 0)
> > > and
> > > > getXXXLength() is any way going to be the sliced BB's limit.
> > > >
> > > > But in the 2nd approach we may end up in creating lot of small
> objects
> > > even
> > > > while doing comparison.
> > > >
> > > > Now the next problem that comes is what to do with the getXXXArray()
> > > APIs.
> > > > If one sees hasArray() as false (a DBB backed Cell) and uses the
> > > > getXXXArray() API along with offset

Re: Please welcome our latest new committer, Virag Kothari

[Nick Dimiduk]

Thanks a lot Virag for your contributions and welcome aboard!

-n

On Fri, Dec 5, 2014 at 12:04 PM, Andrew Purtell  wrote:

> Please welcome our latest new committer, Virag Kothari. Virag
> ​is
> actively working on
> ​a
>
> ​one
>  million regions scalability challenge
> ​ (!) at his current place of employment​
> . He's been a recent frequent contributor and collaborator on changes and
> backports related to metadata tables, ZooKeeper, and the Master.
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Re: HBase - Semantic Versioning

[Nick Dimiduk]

We have a section on Server-Side Limited API Compatibility but what about
similar limited compatibility on client side? We use those same annotation
{stable,evolving,unstable} in client-side classes. Same rules apply as
server-side?

I got to thinking about this again because I recently came back to thinking
about changes/improvements to the DataType API. It was added as Evolving,
but I'm thinking it should have been Unstable from the onset to give it
time to bake.

On Fri, Dec 5, 2014 at 2:02 PM, lars hofhansl  wrote:

> I think we've given this enough time, let's add it.Note that nothing is
> set in stone, and the semantic versioning doc is itself semantically
> versioned. :)We can always change/augment/clarify later.
> -- Lars
>
>   From: Enis Söztutar 
>  To: "dev@hbase.apache.org" ; lars hofhansl <
> la...@apache.org>
> Cc: Sean Busbey 
>  Sent: Monday, November 24, 2014 5:00 PM
>  Subject: Re: HBase - Semantic Versioning
>
> I've created https://issues.apache.org/jira/browse/HBASE-12568 for
> putting this to the book, and making it official.
> Enis
>
>
> On Fri, Nov 21, 2014 at 11:15 PM, lars hofhansl  wrote:
>
> Hey Sean,
> thanks for taking a look. All good points.Send me your gmail id offlist,
> I'll add you as editor (maybe in suggest mode). Might be easier that way.
> If possible I would like to keep it to two pages total (otherwise nobody
> will ever read it :) )(I tried one page, but that was not possible)
>
> -- Lars
>   From: Sean Busbey 
>  To: dev 
> Cc: lars hofhansl 
>  Sent: Friday, November 21, 2014 5:19 PM
>  Subject: Re: HBase - Semantic Versioning
>
> First, this is excellent work and will help greatly with planning around
> HBase deployments. I think the document is big enough, of wide enough
> interest, and important enough that we should keep it as a page in the site
> outside of the ref guide. Maybe it could live near wherever we currently
> keep our bylaws?
> A very brief restatement of how major, minor, and patch map to version
> strings X.Y.Z would help make the compatibility matrix easier to follow for
> those not familiar with semantic versioning. Some may go read the full
> reference, but most probably won't. Maybe "Summary" could be retitled
> "Version Changes" and the bullet points could be preceded with a couple of
> sentences.
> I notice the document doesn't make any reference to our use of
> InterfaceAudience[1]. Can we update it to do so?
> Specifically, what is covered in "Client API", is it just stuff that's
> IA.Public in hbase-client or IA.Public anywhere? If the former, then what
> covers the rest?
> I think the section on "server side limited API compatibility" is for
> things marked IA.LimitedPrivate, but it would be nice to have it spelled
> out.
> The document covers InterfaceStability markings but only for server side.
> Our current ref guide[1] covers them only for things marked public. Can we
> unify this one way or the other? I suspect the answer is that we ought to
> have them for both.
> [1]: http://hbase.apache.org/book.html#d0e21466
>
>
> On Fri, Nov 21, 2014 at 6:15 PM, Stack  wrote:
>
> How should we progress here?  Unless objection by tomorrow -- a week --
> then lets just adopt this doc?  I can squash it into our dev section in
> refguide.
> St.Ack
>
> On Sat, Nov 15, 2014 at 5:06 PM, lars hofhansl  wrote:
>
> > As we approach the released of HBase 1.0.0, your PMC has been working
> hard
> > on documenting the exact compatibility guarantees we plan to support for
> > HBase versions going forward.
> > You can find the current version of the document here:
> >
> >
> https://docs.google.com/document/d/1p5pP7v2OuzSSaomK2S2v7sfKky1Hex6OqwsJO0sZTUY/edit?usp=sharing
> >
> > For convenience I am also including the entire text at the end of this
> > email (hopefully the formatting comes through).
> > Please have a look and let us know what you think.While we cannot
> possibly
> > include provisions for every corner case, this should be as comprehensive
> > as possible.Note that the semantic versioning document is itself
> > semantically versioned :)
> > Thanks.
> > -- Lars
> > --
> >
> > HBase Semantic Versioning - 1.0.4As HBase approaches its 1.0.0 version we
> > should start using semantic versioning.In addition to the usual API
> > versioning considerations HBase has other compatibility dimensions that
> we
> > need to consider.
> > Compatibility Dimensions
> >
> >- Client-Server wire protocol compatibility
> >
> >- Allows updating client and server out of sync.
> >- We could only allow upgrading the server first. I.e. the server
> would
> > be backward compatible to an old client, that way new APIs are OK.
> >- Example: A user should be able to use an old client to connect to an
> > upgraded cluster.
> >
> >- Server-Server protocol compatibility
> >
> >- Servers of different versions can co-exist in the same cluster.
> >- The wire protocol between servers is compatible.
> >- W

Re: HBase - Semantic Versioning

[Nick Dimiduk]

Right. So either two sections or simply remove the specificity of
"Server-Side".

On Fri, Dec 5, 2014 at 4:19 PM, lars hofhansl  wrote:

> I'd think so. So maybe the section for client API compatibility should
> break down into the same subclasses.
>   From: Nick Dimiduk 
>  To: hbase-dev ; lars hofhansl 
> Cc: Enis Söztutar ; Sean Busbey 
>  Sent: Friday, December 5, 2014 2:32 PM
>  Subject: Re: HBase - Semantic Versioning
>
> We have a section on Server-Side Limited API Compatibility but what about
> similar limited compatibility on client side? We use those same annotation
> {stable,evolving,unstable} in client-side classes. Same rules apply as
> server-side?
>
> I got to thinking about this again because I recently came back to thinking
> about changes/improvements to the DataType API. It was added as Evolving,
> but I'm thinking it should have been Unstable from the onset to give it
> time to bake.
>
>
>
> On Fri, Dec 5, 2014 at 2:02 PM, lars hofhansl  wrote:
>
> > I think we've given this enough time, let's add it.Note that nothing is
> > set in stone, and the semantic versioning doc is itself semantically
> > versioned. :)We can always change/augment/clarify later.
> > -- Lars
> >
> >  From: Enis Söztutar 
> >  To: "dev@hbase.apache.org" ; lars hofhansl <
> > la...@apache.org>
> > Cc: Sean Busbey 
> >  Sent: Monday, November 24, 2014 5:00 PM
> >  Subject: Re: HBase - Semantic Versioning
> >
> > I've created https://issues.apache.org/jira/browse/HBASE-12568 for
> > putting this to the book, and making it official.
> > Enis
> >
> >
> > On Fri, Nov 21, 2014 at 11:15 PM, lars hofhansl 
> wrote:
> >
> > Hey Sean,
> > thanks for taking a look. All good points.Send me your gmail id offlist,
> > I'll add you as editor (maybe in suggest mode). Might be easier that way.
> > If possible I would like to keep it to two pages total (otherwise nobody
> > will ever read it :) )(I tried one page, but that was not possible)
> >
> > -- Lars
> >  From: Sean Busbey 
> >  To: dev 
> > Cc: lars hofhansl 
> >  Sent: Friday, November 21, 2014 5:19 PM
> >  Subject: Re: HBase - Semantic Versioning
> >
> > First, this is excellent work and will help greatly with planning around
> > HBase deployments. I think the document is big enough, of wide enough
> > interest, and important enough that we should keep it as a page in the
> site
> > outside of the ref guide. Maybe it could live near wherever we currently
> > keep our bylaws?
> > A very brief restatement of how major, minor, and patch map to version
> > strings X.Y.Z would help make the compatibility matrix easier to follow
> for
> > those not familiar with semantic versioning. Some may go read the full
> > reference, but most probably won't. Maybe "Summary" could be retitled
> > "Version Changes" and the bullet points could be preceded with a couple
> of
> > sentences.
> > I notice the document doesn't make any reference to our use of
> > InterfaceAudience[1]. Can we update it to do so?
> > Specifically, what is covered in "Client API", is it just stuff that's
> > IA.Public in hbase-client or IA.Public anywhere? If the former, then what
> > covers the rest?
> > I think the section on "server side limited API compatibility" is for
> > things marked IA.LimitedPrivate, but it would be nice to have it spelled
> > out.
> > The document covers InterfaceStability markings but only for server side.
> > Our current ref guide[1] covers them only for things marked public. Can
> we
> > unify this one way or the other? I suspect the answer is that we ought to
> > have them for both.
> > [1]: http://hbase.apache.org/book.html#d0e21466
> >
> >
> > On Fri, Nov 21, 2014 at 6:15 PM, Stack  wrote:
> >
> > How should we progress here?  Unless objection by tomorrow -- a week --
> > then lets just adopt this doc?  I can squash it into our dev section in
> > refguide.
> > St.Ack
> >
> > On Sat, Nov 15, 2014 at 5:06 PM, lars hofhansl  wrote:
> >
> > > As we approach the released of HBase 1.0.0, your PMC has been working
> > hard
> > > on documenting the exact compatibility guarantees we plan to support
> for
> > > HBase versions going forward.
> > > You can find the current version of the document here:
> > >
> > >
> >
> https://docs.google.com/document/d/1p5pP7v2OuzSSaomK2S2v7sfKky1Hex6OqwsJO0sZTUY/edit?usp=sharing
> > >

Re: Replication terminology "master-master"

[Nick Dimiduk]

I suggest we drop the lingo and just say what we mean explicitly: "A
cluster may act as both a replication source and destination
simultaneously."

On Tuesday, December 9, 2014, Misty Stanley-Jones <
mstanleyjo...@cloudera.com> wrote:

> Can I get some consensus on what we should be saying about different
> replication types? It's a bit over my head and I don't feel comfortable
> making a unilateral decision.
>
> On Sun, Nov 30, 2014 at 8:40 AM, Michael Segel  >
> wrote:
>
> > Both clusters are alive, but the terms active/passive means who’s serving
> > the data.
> >
> > Your ‘master’ is the HBase cluster which is r/w and serving data.
> >
> > Your ‘slave’ is the cluster that is passive or only serving read only
> data.
> >
> > To your point that active/passive may be incorrect because you can read
> > from the passive, too.
> >
> > Peer to Peer may be incorrect in that while both are peers, you’re
> > actively writing to one, while the other gets a copy of the data and is
> > passive.
> > Understanding that in context a HBase cluster can be active for one data
> > set and passive for another.
> >
> > Active/Active would be that I could write to either and there would be
> > some form of eventual consistency.
> >
> > On Nov 28, 2014, at 1:15 AM, Misty Stanley-Jones <
> > mstanleyjo...@cloudera.com > wrote:
> >
> > > I don't think active/passive is what we mean here, since both clusters
> > are
> > > fully "active" from the perspective of clients, right? The slave
> cluster
> > is
> > > not actually read-only, is it?
> > >
> > > On Thu, Nov 27, 2014 at 10:50 PM, Michael Segel <
> > michael_se...@hotmail.com >
> > > wrote:
> > >
> > >> master - master?
> > >>
> > >> Do you mean active - active ?
> > >>
> > >> replace master and slave with active and passive.
> > >>
> > >>
> > >> On Nov 25, 2014, at 3:26 AM, Misty Stanley-Jones <
> > >> mstanleyjo...@cloudera.com > wrote:
> > >>
> > >>> Hi all,
> > >>>
> > >>> I think "master-master" is a term that should be re-thought. It is
> not
> > >>> really a "type" of replication, but refers to a characteristic of  a
> > >>> cluster, specifically a cluster which participates in multiple
> clusters
> > >>> with different roles -- it is a slave in one cluster and a master in
> > >>> another cluster. I think with the current terminology, people confuse
> > it
> > >>> with "cyclical" replication, in which two clusters replicate to each
> > >> other,
> > >>> and eventually each has all the data from both.
> > >>>
> > >>> Since master-master in this sense is really not a type of
> replication,
> > I
> > >>> think we should just scrap it. You can have master-slave replication
> or
> > >>> cyclical replication, or a combination. With master-slave
> replication,
> > a
> > >>> cluster can fulfill both roles at the same time, as long as it is in
> > >>> different clusters. This is easy to understand as a sort of recursive
> > >>> cascade.
> > >>>
> > >>> Am I explaining it right, and what do you guys think about changing
> our
> > >>> terminology?
> > >>>
> > >>> Thanks,
> > >>> Misty
> > >>
> > >>
> >
> >
>

Re: RS disk capacity limits

[Nick Dimiduk]

Correct, you want more spindles/TB. Furthermore, you'll need RAM to use
that storage effectively. GB RAM/TB of disk will very depending on your
access patterns. 20 TB raw storage is about 6.6TB after replication. Even
with compressed BlockCache and a compression ratio of 0.3, it'll be
difficult to keep that much data hot.

On Friday, December 12, 2014, 张铎  wrote:

> I think 10 disks each 2TB is better.
> A disk can only seek about 50 times per second no matter it is 10TB or 2TB,
> so more disks means you can do more seeks and increase the random read
> write performance.
>
> 2014-12-13 9:04 GMT+08:00 Krishna >:
> >
> > Hi,
> >
> > Is there any logical/practical limit on HBase RS storage size?
> > Which works better for HBase - a region server with 10 disks that are
> each
> > 2 TB or 2 disks that are each 10TB?
> > I remember, one of the recommendations is to keep each disk on RS to be
> > less than 6 TB - is that correct?
> >
> > Thanks
> >
>

Re: A face-lift for 1.0

[Nick Dimiduk]

For those not following closely in JIRAland, I've two changes that are
ready to go. First, there's transition over to a bootstrap-based layout for
our home page. This work is done in HBASE-12688. This improves the looks of
things and will make it pretty easy to update our look-and-feel in the
future. Second, I fixed a build problem where the online book wasn't
getting its intended styling. This is done in HBASE-12687. I'd like to
update the book to look the same as the front-page, but getting styles into
docbook is proving non-trivial.

Anyway, both of these changes are pushed to master and we're ready for a
site re-build with the new look. I'll make that happen tomorrow morning
unless I hear actionable objections.

You can get a preview of things to come over one
http://people.apache.org/~ndimiduk/site/

Thanks,
Nick

On Fri, Dec 5, 2014 at 12:29 PM, Stack  wrote:
>
> Thanks. I've been having a dialog w/ your crew that has been going on a
> while... was wondering if any progress.
> Grand,
> St.Ack
>
> On Fri, Dec 5, 2014 at 11:55 AM, Ryan Rawson  wrote:
>
> > I'm checking to see if our marketing and web team can help.  The
> > primary requirement is going to be ditching the mvn:site from the
> > front page.  "reskinning it" might not be so easy.
> >
> > -ryan
> >
> > On Thu, Dec 4, 2014 at 9:52 AM, lars hofhansl  wrote:
> > > +1
> > > I just came across one of the various HBase vs. Cassandra articles, and
> > one of the main tenants of the articles was how much better the Cassandra
> > documentation was.Thank god we have Misty now. :)
> > >
> > > (not sure how much just a skin would help, but it surely won't hurt)
> > >
> > > -- Lars
> > >   From: Nick Dimiduk 
> > >  To: hbase-dev 
> > >  Sent: Tuesday, December 2, 2014 9:46 AM
> > >  Subject: A face-lift for 1.0
> > >
> > > Heya,
> > >
> > > In mind of the new release, I was thinking we should clean up our act a
> > > little bit in regard to hbase.apache.org and our book. Just because
> the
> > > project started in 2007 doesn't mean we need a site that looks like
> it's
> > > from 2007. Phoenix's site looks great in this regard.
> > >
> > > For the home page, I was thinking of converting it over to bootstrap
> [0]
> > so
> > > that it'll be easier to pick up theme, either on of our own or
> something
> > > pre-canned [1]. I'm no web designer, but the idea is this would make it
> > > easier for someone who is to help us out.
> > >
> > > For the book, I just want to skin it -- no intention of changing
> docbook
> > > part (such a decision I'll leave up to Misty). I'm less sure on this
> > > project, but Riak's docs are a nice inspiration.
> > >
> > > What do you think? Do we know any web designers who can help out with
> the
> > > CSS?
> > >
> > > -n
> > >
> > > [0]: http://getbootstrap.com
> > > [1]: https://wrapbootstrap.com/
> > > [2]: http://docs.basho.com/riak/latest/
> > >
> > >
> > >
> >
>

Re: A face-lift for 1.0

[Nick Dimiduk]

Tweaking the layout of the website goes one of two ways. Either there's a
configuration point exposed from the maven skin or there isn't. If there
is, it's simply editing the appropriate custom tag in site.xml. If not,
we'll need to bring back the velocity site.vm template. Configurations are
documented here:
http://andriusvelykis.github.io/reflow-maven-skin/skin/config.html

Tweaking visuals is now based on the theme. We can either choose another
bootswatch theme, or write our own. That stuff is documented here:
http://andriusvelykis.github.io/reflow-maven-skin/skin/themes/

Right now the site is separate from the book. In theory we could move book
content over to become site content, in which case it would be managed by
this same plugin. Short of that, we get into applying style via the docbook
plugin. I've looked into this a bit; it's not nearly as easy as applying
reflow-maven-skin. The current leads I have for this are
https://github.com/lcahlander/docbook and
https://github.com/pmartin/phing-documentation-docbook/commit/8d8f0b81951c4e07420083b204599a6b9ef00537
 .

Honestly though, if we're looking at moving away from docbook, I think we
should consider a more modern toolset, Sphinx-doc, for example:
http://sphinx-doc.org

On Tue, Dec 16, 2014 at 8:21 PM, Misty Stanley-Jones <
mstanleyjo...@cloudera.com> wrote:
>
> Absolutely fantastic!!! Got pointers to how tweaking the website would
> work?
>
> In the new year I hope to really get started on a restructure of the Ref
> Guide. I've thought about asking to move to AsciiDOC or MarkDown but I'd
> like to do a proof-of-concept and see if it really gets us anything we
> don't already have with Docbook. It's less of a potential value since we
> are not hosted on Github, which has great integration with AsciiDOC and
> MarkDown. I'm very interested in improving the look and feel of the doc. I
> think a lot of it will be structural -- reorganizing and re-chunking
> content.
>
> In the meantime, theming the Docbook is not as hard as you might think.
> Have a look at the XSLT files. (I know, famous last words).
>
> On Wed, Dec 17, 2014 at 1:21 PM, Nick Dimiduk  wrote:
>
> > For those not following closely in JIRAland, I've two changes that are
> > ready to go. First, there's transition over to a bootstrap-based layout
> for
> > our home page. This work is done in HBASE-12688. This improves the looks
> of
> > things and will make it pretty easy to update our look-and-feel in the
> > future. Second, I fixed a build problem where the online book wasn't
> > getting its intended styling. This is done in HBASE-12687. I'd like to
> > update the book to look the same as the front-page, but getting styles
> into
> > docbook is proving non-trivial.
> >
> > Anyway, both of these changes are pushed to master and we're ready for a
> > site re-build with the new look. I'll make that happen tomorrow morning
> > unless I hear actionable objections.
> >
> > You can get a preview of things to come over one
> > http://people.apache.org/~ndimiduk/site/
> >
> > Thanks,
> > Nick
> >
> > On Fri, Dec 5, 2014 at 12:29 PM, Stack  wrote:
> > >
> > > Thanks. I've been having a dialog w/ your crew that has been going on a
> > > while... was wondering if any progress.
> > > Grand,
> > > St.Ack
> > >
> > > On Fri, Dec 5, 2014 at 11:55 AM, Ryan Rawson 
> wrote:
> > >
> > > > I'm checking to see if our marketing and web team can help.  The
> > > > primary requirement is going to be ditching the mvn:site from the
> > > > front page.  "reskinning it" might not be so easy.
> > > >
> > > > -ryan
> > > >
> > > > On Thu, Dec 4, 2014 at 9:52 AM, lars hofhansl 
> > wrote:
> > > > > +1
> > > > > I just came across one of the various HBase vs. Cassandra articles,
> > and
> > > > one of the main tenants of the articles was how much better the
> > Cassandra
> > > > documentation was.Thank god we have Misty now. :)
> > > > >
> > > > > (not sure how much just a skin would help, but it surely won't
> hurt)
> > > > >
> > > > > -- Lars
> > > > >   From: Nick Dimiduk 
> > > > >  To: hbase-dev 
> > > > >  Sent: Tuesday, December 2, 2014 9:46 AM
> > > > >  Subject: A face-lift for 1.0
> > > > >
> > > > > Heya,
> > > > >
> > > > > In mind of the new release, I was thinking we should clean up our
> &

Re: A face-lift for 1.0

[Nick Dimiduk]

Any chance of fixing this by way of a contribution back to the maven-skin
maintainers? We can avoid bringing back the site.vm if we leave this in
their hands.

On Tue, Dec 30, 2014 at 12:11 PM, Dima Spivak  wrote:

> Ooh, good call, guys. Yeah, looks like all we'd need to do is move
> bootstrap.min.css and bootstrap-responsive.min.css onto our server and link
> to it relatively instead of with absolute links it has now. Seeing as how
> both of those CSS files are Apache License, should be easy.
>
> -Dima
>
> On Tue, Dec 30, 2014 at 11:54 AM, Elliott Clark  wrote:
>
> > Yeah the js and css are all loaded though a cdn. It should be pretty easy
> > to change the urls to be protocol relative and then things should work.
> >
> > On Tue, Dec 30, 2014 at 11:17 AM, Enis Söztutar 
> > wrote:
> >
> > > I had the same problem. We link to CSS which is http instead of forking
> > and
> > > serving it in the site (I believe this is the default practice). My
> > chrome
> > > extension refuses to connect to http links causing rendering problems.
> > >
> > > Enis
> > >
> > > On Tue, Dec 30, 2014 at 11:00 AM, Dima Spivak 
> > > wrote:
> > >
> > > > Not sure if this is something to address in this thread or if I
> should
> > > file
> > > > a separate JIRA, but for some reason, accessing the site over https
> > gets
> > > > rid of the pretty CSS. Seems to happen in Chrome and Firefox. Anyone
> > > have a
> > > > clue why?
> > > >
> > > > -Dima
> > > >
> > > > On Wed, Dec 17, 2014 at 10:53 AM, Nick Dimiduk 
> > > wrote:
> > > >
> > > > > Tweaking the layout of the website goes one of two ways. Either
> > > there's a
> > > > > configuration point exposed from the maven skin or there isn't. If
> > > there
> > > > > is, it's simply editing the appropriate custom tag in site.xml. If
> > not,
> > > > > we'll need to bring back the velocity site.vm template.
> > Configurations
> > > > are
> > > > > documented here:
> > > > > http://andriusvelykis.github.io/reflow-maven-skin/skin/config.html
> > > > >
> > > > > Tweaking visuals is now based on the theme. We can either choose
> > > another
> > > > > bootswatch theme, or write our own. That stuff is documented here:
> > > > > http://andriusvelykis.github.io/reflow-maven-skin/skin/themes/
> > > > >
> > > > > Right now the site is separate from the book. In theory we could
> move
> > > > book
> > > > > content over to become site content, in which case it would be
> > managed
> > > by
> > > > > this same plugin. Short of that, we get into applying style via the
> > > > docbook
> > > > > plugin. I've looked into this a bit; it's not nearly as easy as
> > > applying
> > > > > reflow-maven-skin. The current leads I have for this are
> > > > > https://github.com/lcahlander/docbook and
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/pmartin/phing-documentation-docbook/commit/8d8f0b81951c4e07420083b204599a6b9ef00537
> > > > >  .
> > > > >
> > > > > Honestly though, if we're looking at moving away from docbook, I
> > think
> > > we
> > > > > should consider a more modern toolset, Sphinx-doc, for example:
> > > > > http://sphinx-doc.org
> > > > >
> > > > > On Tue, Dec 16, 2014 at 8:21 PM, Misty Stanley-Jones <
> > > > > mstanleyjo...@cloudera.com> wrote:
> > > > > >
> > > > > > Absolutely fantastic!!! Got pointers to how tweaking the website
> > > would
> > > > > > work?
> > > > > >
> > > > > > In the new year I hope to really get started on a restructure of
> > the
> > > > Ref
> > > > > > Guide. I've thought about asking to move to AsciiDOC or MarkDown
> > but
> > > > I'd
> > > > > > like to do a proof-of-concept and see if it really gets us
> anything
> > > we
> > > > > > don't already have with Docbook. It's less of a potential value
> > since
> > > > we
> > > > > > are not hosted on Github, which has great integration with
> AsciiDOC
> &g

Re: Please welcome our latest committer, the mighty Liu Shaohui!

[Nick Dimiduk]

Welcome aboard and thanks for the mighty contributions Shaohui!

On Wed, Jan 7, 2015 at 8:04 AM, Stack  wrote:

> Liu Shaohui has been debugging and fixing ugly production issues for a long
> time now contributing back his quality fixes. We are glad to have him on
> board as our newest HBase committer.  Please welcome him to the fold.
>
> Yours,
> St.Ack
>