Re: [ANNOUNCE] New HBase committer Lars Francke

[Guanghao Zhang]

Congratulations!

2017-10-26 14:25 GMT+08:00 Yu Li :

> Congratulations!
>
> Best Regards,
> Yu
>
> On 26 October 2017 at 13:39, Anoop John  wrote:
>
> > Congrats and welcome Lars F.
> >
> > -Anoop-
> >
> > On Thu, Oct 26, 2017 at 9:58 AM, ramkrishna vasudevan
> >  wrote:
> > > Welcome Lars..
> > >
> > > On Thu, Oct 26, 2017 at 9:54 AM, Misty Stanley-Jones  >
> > > wrote:
> > >
> > >> Welcome Lars!
> > >>
> > >> On Wed, Oct 25, 2017 at 7:24 PM Jingcheng Du 
> > wrote:
> > >>
> > >> > Congratulations!
> > >> >
> > >> > 2017-10-26 9:45 GMT+08:00 OpenInx :
> > >> >
> > >> > > Congratulations.
> > >> > >
> > >> > > On Thu, Oct 26, 2017 at 9:36 AM, 张铎(Duo Zhang) <
> > palomino...@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > Congratulations!
> > >> > > >
> > >> > > > 2017-10-26 4:35 GMT+08:00 Esteban Gutierrez <
> este...@cloudera.com
> > >:
> > >> > > >
> > >> > > > > Congrats Lars F! well deserved!
> > >> > > > >
> > >> > > > > --
> > >> > > > > Cloudera, Inc.
> > >> > > > >
> > >> > > > >
> > >> > > > > On Wed, Oct 25, 2017 at 3:26 PM, Andrew Purtell <
> > >> apurt...@apache.org
> > >> > >
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > > > Congratulations and welcome!
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > On Wed, Oct 25, 2017 at 12:56 PM, Lars George <
> > >> > lars.geo...@gmail.com
> > >> > > >
> > >> > > > > > wrote:
> > >> > > > > >
> > >> > > > > > > On behalf of the Apache HBase PMC, I am pleased to
> announce
> > >> that
> > >> > > Lars
> > >> > > > > > > Francke has accepted the PMC's invitation to become a
> > committer
> > >> > on
> > >> > > > the
> > >> > > > > > > project.
> > >> > > > > > >
> > >> > > > > > > We appreciate all of Lars' great work thus far and look
> > forward
> > >> > to
> > >> > > > > > > continued involvement.
> > >> > > > > > >
> > >> > > > > > > Please join me in congratulating LarsF! (Opting to use
> last
> > >> name
> > >> > > > > > > initials as we now have three Lars' as committers)
> > >> > > > > > >
> > >> > > > > > > --
> > >> > > > > > > Best regards,
> > >> > > > > > > LarsG
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > --
> > >> > > > > > Best regards,
> > >> > > > > > Andrew
> > >> > > > > >
> > >> > > > > > Words like orphans lost among the crosstalk, meaning torn
> from
> > >> > > truth's
> > >> > > > > > decrepit hands
> > >> > > > > >- A23, Crosstalk
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > ==
> > >> > > Openinx  blog : http://openinx.github.io
> > >> > >
> > >> > > TO BE A GREAT HACKER !
> > >> > > ==
> > >> > >
> > >> >
> > >>
> >
>

Re: [ANNOUNCE] New HBase committer Lars Francke

[Yu Li]

Congratulations!

Best Regards,
Yu

On 26 October 2017 at 13:39, Anoop John  wrote:

> Congrats and welcome Lars F.
>
> -Anoop-
>
> On Thu, Oct 26, 2017 at 9:58 AM, ramkrishna vasudevan
>  wrote:
> > Welcome Lars..
> >
> > On Thu, Oct 26, 2017 at 9:54 AM, Misty Stanley-Jones 
> > wrote:
> >
> >> Welcome Lars!
> >>
> >> On Wed, Oct 25, 2017 at 7:24 PM Jingcheng Du 
> wrote:
> >>
> >> > Congratulations!
> >> >
> >> > 2017-10-26 9:45 GMT+08:00 OpenInx :
> >> >
> >> > > Congratulations.
> >> > >
> >> > > On Thu, Oct 26, 2017 at 9:36 AM, 张铎(Duo Zhang) <
> palomino...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Congratulations!
> >> > > >
> >> > > > 2017-10-26 4:35 GMT+08:00 Esteban Gutierrez  >:
> >> > > >
> >> > > > > Congrats Lars F! well deserved!
> >> > > > >
> >> > > > > --
> >> > > > > Cloudera, Inc.
> >> > > > >
> >> > > > >
> >> > > > > On Wed, Oct 25, 2017 at 3:26 PM, Andrew Purtell <
> >> apurt...@apache.org
> >> > >
> >> > > > > wrote:
> >> > > > >
> >> > > > > > Congratulations and welcome!
> >> > > > > >
> >> > > > > >
> >> > > > > > On Wed, Oct 25, 2017 at 12:56 PM, Lars George <
> >> > lars.geo...@gmail.com
> >> > > >
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > > On behalf of the Apache HBase PMC, I am pleased to announce
> >> that
> >> > > Lars
> >> > > > > > > Francke has accepted the PMC's invitation to become a
> committer
> >> > on
> >> > > > the
> >> > > > > > > project.
> >> > > > > > >
> >> > > > > > > We appreciate all of Lars' great work thus far and look
> forward
> >> > to
> >> > > > > > > continued involvement.
> >> > > > > > >
> >> > > > > > > Please join me in congratulating LarsF! (Opting to use last
> >> name
> >> > > > > > > initials as we now have three Lars' as committers)
> >> > > > > > >
> >> > > > > > > --
> >> > > > > > > Best regards,
> >> > > > > > > LarsG
> >> > > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > --
> >> > > > > > Best regards,
> >> > > > > > Andrew
> >> > > > > >
> >> > > > > > Words like orphans lost among the crosstalk, meaning torn from
> >> > > truth's
> >> > > > > > decrepit hands
> >> > > > > >- A23, Crosstalk
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > ==
> >> > > Openinx  blog : http://openinx.github.io
> >> > >
> >> > > TO BE A GREAT HACKER !
> >> > > ==
> >> > >
> >> >
> >>
>

[jira] [Created] (HBASE-19092) Make Tag IA.LimitedPrivate and expose for CPs

[ramkrishna.s.vasudevan (JIRA)]

ramkrishna.s.vasudevan created HBASE-19092:
--

 Summary: Make Tag IA.LimitedPrivate and expose for CPs
 Key: HBASE-19092
 URL: https://issues.apache.org/jira/browse/HBASE-19092
 Project: HBase
  Issue Type: Sub-task
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 2.0.0-beta-1


We need to make tags as LimitedPrivate as some use cases are trying to use tags 
like timeline server. The same topic was discussed in dev@ and also in 
HBASE-18995.
Shall we target this for beta1 - cc [~saint@gmail.com].
So once we do this all related Util methods and APIs should also move to 
LimitedPrivate Util classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19091) Code annotation wrote "BinaryComparator" instead of "LongComparator"

[Qilin Cao (JIRA)]

Qilin Cao created HBASE-19091:
-

 Summary: Code annotation wrote "BinaryComparator" instead of 
"LongComparator"
 Key: HBASE-19091
 URL: https://issues.apache.org/jira/browse/HBASE-19091
 Project: HBase
  Issue Type: Improvement
  Components: Client
Affects Versions: 3.0.0
Reporter: Qilin Cao
Assignee: Qilin Cao
Priority: Minor


LongComparator class code annotation wrote "BinaryComparator" instead of 
"LongComparator"




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [ANNOUNCE] New HBase committer Lars Francke

[Anoop John]

Congrats and welcome Lars F.

-Anoop-

On Thu, Oct 26, 2017 at 9:58 AM, ramkrishna vasudevan
 wrote:
> Welcome Lars..
>
> On Thu, Oct 26, 2017 at 9:54 AM, Misty Stanley-Jones 
> wrote:
>
>> Welcome Lars!
>>
>> On Wed, Oct 25, 2017 at 7:24 PM Jingcheng Du  wrote:
>>
>> > Congratulations!
>> >
>> > 2017-10-26 9:45 GMT+08:00 OpenInx :
>> >
>> > > Congratulations.
>> > >
>> > > On Thu, Oct 26, 2017 at 9:36 AM, 张铎(Duo Zhang) 
>> > > wrote:
>> > >
>> > > > Congratulations!
>> > > >
>> > > > 2017-10-26 4:35 GMT+08:00 Esteban Gutierrez :
>> > > >
>> > > > > Congrats Lars F! well deserved!
>> > > > >
>> > > > > --
>> > > > > Cloudera, Inc.
>> > > > >
>> > > > >
>> > > > > On Wed, Oct 25, 2017 at 3:26 PM, Andrew Purtell <
>> apurt...@apache.org
>> > >
>> > > > > wrote:
>> > > > >
>> > > > > > Congratulations and welcome!
>> > > > > >
>> > > > > >
>> > > > > > On Wed, Oct 25, 2017 at 12:56 PM, Lars George <
>> > lars.geo...@gmail.com
>> > > >
>> > > > > > wrote:
>> > > > > >
>> > > > > > > On behalf of the Apache HBase PMC, I am pleased to announce
>> that
>> > > Lars
>> > > > > > > Francke has accepted the PMC's invitation to become a committer
>> > on
>> > > > the
>> > > > > > > project.
>> > > > > > >
>> > > > > > > We appreciate all of Lars' great work thus far and look forward
>> > to
>> > > > > > > continued involvement.
>> > > > > > >
>> > > > > > > Please join me in congratulating LarsF! (Opting to use last
>> name
>> > > > > > > initials as we now have three Lars' as committers)
>> > > > > > >
>> > > > > > > --
>> > > > > > > Best regards,
>> > > > > > > LarsG
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Best regards,
>> > > > > > Andrew
>> > > > > >
>> > > > > > Words like orphans lost among the crosstalk, meaning torn from
>> > > truth's
>> > > > > > decrepit hands
>> > > > > >- A23, Crosstalk
>> > > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > ==
>> > > Openinx  blog : http://openinx.github.io
>> > >
>> > > TO BE A GREAT HACKER !
>> > > ==
>> > >
>> >
>>

[jira] [Created] (HBASE-19090) Add config 'hbase.systemtables.compacting.memstore.type' to docs

[ramkrishna.s.vasudevan (JIRA)]

ramkrishna.s.vasudevan created HBASE-19090:
--

 Summary: Add config 'hbase.systemtables.compacting.memstore.type' 
to docs
 Key: HBASE-19090
 URL: https://issues.apache.org/jira/browse/HBASE-19090
 Project: HBase
  Issue Type: Sub-task
Reporter: ramkrishna.s.vasudevan
 Fix For: 2.0.0-alpha-4


As discussed in parent JIRA the new config 
'hbase.systemtables.compacting.memstore.type' has to be added to docs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

[Misty Stanley-Jones]

If we keep it as is, how and where can we capture this knowledge to save
future contributors from having to ask again?

On Wed, Oct 25, 2017 at 9:22 AM Josh Elser  wrote:

> :) no worries, Appy. These are good questions.
>
> It really comes down to the question: would HBase ever provide multiple
> metrics implementations for users?
>
> As we know metrics in HBase now, there isn't any reason to support
> multiple implementations of metrics. We have one implementation which is
> optimal for people to use.
>
> One plausible use-case I can see being built is a metrics implementation
> that natively uses something _other than_ Hadoop metrics2. Something you
> may not have seen yet is the translation-layer from Dropwizard Metrics
> to Metrics2 via HBaseMetrics2HadoopMetricsAdapter.java.
>
> I could see a world where folks would want to build an integration with
> metrics-library1 to support the metrics platform for their $business1.
> $business2 might want to use metrics-library2 that can automatically
> push to something. As we know all too well, there may be conflicting
> dependencies between metrics-library1 and metrics-library2 to prevent
> them from successfully functioning on the classpath at the same time.
> Additionally, $business1 may have a hard requirement to not deploy
> metrics-library2 (and vice versa). One final concern, bundling our
> "default" DropwizardMetrics 3-based implementation could cause headaches
> for users who want to build their own metrics-api implementation.
>
> Granted, all of the above is hypothetical, but I think leaving this
> flexibility in place is worth the separation of logic.
>
> On 10/25/17 3:35 AM, Apekshit Sharma wrote:
> > Hi Josh
> >
> > You're right that naming doesn't make it clear, but Enis added a really
> > great description in README of hbase-metrics-api to explain what's in
> each
> > module. However it's not obvious why are we splitting things into
> separate
> > module, as opposed to say, separating implementation in a separate "sub"
> > package.
> >
> > I don't know Avatica, but as you clearly state, one of the requirements
> was
> > being able to plug in different implementations. Using service provider
> > clearly makes sense in that case, so does keeping the implementation in a
> > separate jar to avoid loading it if not needed.
> > But in case of HBase, even if we have multiple implementations
> > (hypothetically, because it doesn't seem probable), since the only user
> > will be HBase and all modules will always be in classpath, it doesn't
> > really get us anything. Right?
> > I dug into this code first time today and just learnt about service
> > providers, so i may be off, in which case please correct me. Thank you!
> >
> > On Tue, Oct 24, 2017 at 8:25 PM, Josh Elser  wrote:
> >
> >> Hey Appy,
> >>
> >> I think Enis essentially copied what I was originally trying to do. Up
> in
> >> Avatica[1], I made a similar API Maven module which just had interfaces.
> >> The implementation was them split up into a different module to avoid
> the
> >> implementation details of the API (specifically, using Dropwizard3) from
> >> "infecting" anyone who just wanted the API. Implementations of the
> metrics
> >> API could be picked up via ServiceLoader.
> >>
> >> So, here in HBase, our "hbase-metrics" module is really an
> implementation
> >> of hbase-metrics-api for dropwizard-metrics 3.2.1 (the naming just loses
> >> that detail).
> >>
> >> In Avatica, I wanted to make sure that people could use a metrics
> library
> >> implementation of their choosing (e.g. tied to whatever kind of
> container
> >> or app-server you're deploying Avatica). In HBase, that isn't such a
> >> concern -- we publish via Metrics2 and that's it.
> >>
> >> That said, I could see a place where this separation enables some extra
> >> functionality with less headache, but I, admittedly, don't have a
> concrete
> >> use-case behind it.
> >>
> >> - Josh
> >>
> >> [1] https://github.com/apache/calcite-avatica
> >>
> >> On 10/24/17 6:09 PM, Apekshit Sharma wrote:
> >>
> >>> Hi
> >>>
> >>> Am confused why do we have this weird circular dependency between the
> two
> >>> modules: hbase-metrics-api & hbase-metrics. And since maven doesn't
> allow
> >>> it explicitly, this was tucked and hidden by using reflection?
> >>>
> >>> MetricRegistriesImpl[hbase-metrics] implements
> >>> MetricRegistries[hbase-metrics-api].
> >>> MetricRegistriesLoader[hbase-metrics-api] depends on this
> implementation,
> >>> MetricRegistriesImpl, because it instantiates it via reflection
> >>>  >>> 583bfee9c01bc3aed2/hbase-metrics-api/src/main/java/org/
> >>> apache/hadoop/hbase/metrics/MetricRegistriesLoader.java#L39>
> >>> [1].
> >>>
> >>> Can we just move all interfaces and default implementation together
> into
> >>> single module. But i like the idea of keeping implementations in
> separate
> >>> package with "impl" explicitly in package name.
> >>>
> >>> [1]

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

[Sean Busbey]

On Wed, Oct 25, 2017 at 9: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?
>
>

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.

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

[Sean Busbey]

We don't do both at once because the maven assembly plugin isn't very
good at making source tarballs. There's lots of ways for things to go
wrong and give us bad artifacts. most recent example, our 2.0.0-alpha3
release is ~100MiB because it includes shaded jars because prior
commands matter.

Personally, I'd rather update our release process to just use git
archive to create source tarballs off of RC tags.

For example, you can do this to make a source tarball from the
2.0.0-alpha-3 RC tag:

git archive --format=tar.gz
--output=/path/to/rc/artifacts/hbase-2.0.0-alpha-3.tar.gz
--prefix=hbase-2.0.0-alpha-3/ 2.0.0-alpha-3RC0.2

nice and simple. doesn't need a assembly descriptor; says right in the
command which tag the source will correspond to.

In fact, I think I'll do this for the next 1.2 release.

On Wed, Oct 25, 2017 at 6:27 PM, Apekshit Sharma  wrote:
> Any reason why we don't build both together?
>
> On Wed, Oct 25, 2017 at 3:17 PM, Apekshit Sharma  wrote:
>
>> Thanks for the quick reply Busbey. Let me work on fixing the includes list
>> (HBASE-19089 ). Will
>> come back here if more questions arise.
>>
>> --Appy
>>
>> 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.
>>>
>>> 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.
>>>
>>> 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
>>>
>>
>>
>>
>> --
>>
>> -- Appy
>>
>
>
>
> --
>
> -- Appy

Re: [ANNOUNCE] New HBase committer Lars Francke

[ramkrishna vasudevan]

Welcome Lars..

On Thu, Oct 26, 2017 at 9:54 AM, Misty Stanley-Jones 
wrote:

> Welcome Lars!
>
> On Wed, Oct 25, 2017 at 7:24 PM Jingcheng Du  wrote:
>
> > Congratulations!
> >
> > 2017-10-26 9:45 GMT+08:00 OpenInx :
> >
> > > Congratulations.
> > >
> > > On Thu, Oct 26, 2017 at 9:36 AM, 张铎(Duo Zhang) 
> > > wrote:
> > >
> > > > Congratulations!
> > > >
> > > > 2017-10-26 4:35 GMT+08:00 Esteban Gutierrez :
> > > >
> > > > > Congrats Lars F! well deserved!
> > > > >
> > > > > --
> > > > > Cloudera, Inc.
> > > > >
> > > > >
> > > > > On Wed, Oct 25, 2017 at 3:26 PM, Andrew Purtell <
> apurt...@apache.org
> > >
> > > > > wrote:
> > > > >
> > > > > > Congratulations and welcome!
> > > > > >
> > > > > >
> > > > > > On Wed, Oct 25, 2017 at 12:56 PM, Lars George <
> > lars.geo...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > On behalf of the Apache HBase PMC, I am pleased to announce
> that
> > > Lars
> > > > > > > Francke has accepted the PMC's invitation to become a committer
> > on
> > > > the
> > > > > > > project.
> > > > > > >
> > > > > > > We appreciate all of Lars' great work thus far and look forward
> > to
> > > > > > > continued involvement.
> > > > > > >
> > > > > > > Please join me in congratulating LarsF! (Opting to use last
> name
> > > > > > > initials as we now have three Lars' as committers)
> > > > > > >
> > > > > > > --
> > > > > > > Best regards,
> > > > > > > LarsG
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Andrew
> > > > > >
> > > > > > Words like orphans lost among the crosstalk, meaning torn from
> > > truth's
> > > > > > decrepit hands
> > > > > >- A23, Crosstalk
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > ==
> > > Openinx  blog : http://openinx.github.io
> > >
> > > TO BE A GREAT HACKER !
> > > ==
> > >
> >
>

Re: [ANNOUNCE] New HBase committer Lars Francke

[Misty Stanley-Jones]

Welcome Lars!

On Wed, Oct 25, 2017 at 7:24 PM Jingcheng Du  wrote:

> Congratulations!
>
> 2017-10-26 9:45 GMT+08:00 OpenInx :
>
> > Congratulations.
> >
> > On Thu, Oct 26, 2017 at 9:36 AM, 张铎(Duo Zhang) 
> > wrote:
> >
> > > Congratulations!
> > >
> > > 2017-10-26 4:35 GMT+08:00 Esteban Gutierrez :
> > >
> > > > Congrats Lars F! well deserved!
> > > >
> > > > --
> > > > Cloudera, Inc.
> > > >
> > > >
> > > > On Wed, Oct 25, 2017 at 3:26 PM, Andrew Purtell  >
> > > > wrote:
> > > >
> > > > > Congratulations and welcome!
> > > > >
> > > > >
> > > > > On Wed, Oct 25, 2017 at 12:56 PM, Lars George <
> lars.geo...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > On behalf of the Apache HBase PMC, I am pleased to announce that
> > Lars
> > > > > > Francke has accepted the PMC's invitation to become a committer
> on
> > > the
> > > > > > project.
> > > > > >
> > > > > > We appreciate all of Lars' great work thus far and look forward
> to
> > > > > > continued involvement.
> > > > > >
> > > > > > Please join me in congratulating LarsF! (Opting to use last name
> > > > > > initials as we now have three Lars' as committers)
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > LarsG
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Andrew
> > > > >
> > > > > Words like orphans lost among the crosstalk, meaning torn from
> > truth's
> > > > > decrepit hands
> > > > >- A23, Crosstalk
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > ==
> > Openinx  blog : http://openinx.github.io
> >
> > TO BE A GREAT HACKER !
> > ==
> >
>

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: [ANNOUNCE] New HBase committer Lars Francke

[Jingcheng Du]

Congratulations!

2017-10-26 9:45 GMT+08:00 OpenInx :

> Congratulations.
>
> On Thu, Oct 26, 2017 at 9:36 AM, 张铎(Duo Zhang) 
> wrote:
>
> > Congratulations!
> >
> > 2017-10-26 4:35 GMT+08:00 Esteban Gutierrez :
> >
> > > Congrats Lars F! well deserved!
> > >
> > > --
> > > Cloudera, Inc.
> > >
> > >
> > > On Wed, Oct 25, 2017 at 3:26 PM, Andrew Purtell 
> > > wrote:
> > >
> > > > Congratulations and welcome!
> > > >
> > > >
> > > > On Wed, Oct 25, 2017 at 12:56 PM, Lars George  >
> > > > wrote:
> > > >
> > > > > On behalf of the Apache HBase PMC, I am pleased to announce that
> Lars
> > > > > Francke has accepted the PMC's invitation to become a committer on
> > the
> > > > > project.
> > > > >
> > > > > We appreciate all of Lars' great work thus far and look forward to
> > > > > continued involvement.
> > > > >
> > > > > Please join me in congratulating LarsF! (Opting to use last name
> > > > > initials as we now have three Lars' as committers)
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > LarsG
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew
> > > >
> > > > Words like orphans lost among the crosstalk, meaning torn from
> truth's
> > > > decrepit hands
> > > >- A23, Crosstalk
> > > >
> > >
> >
>
>
>
> --
> ==
> Openinx  blog : http://openinx.github.io
>
> TO BE A GREAT HACKER !
> ==
>

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

[Stack]

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: Moving 2.0 forward

[Duo Zhang]

OK, skimmed,  we are in trouble! The in memory compaction just use the same
constructor with normal compaction to construct a StoreScanner, and use it
to do compaction...

We have to provide several preXXX and postXXX for it, at least we should
allow user reset TTL and max versions, and also do filtering on the scanner.

Thanks.



2017-10-26 9:41 GMT+08:00 张铎(Duo Zhang) :

> When adding back the pre(Flush/Compact/Store)ScannerOpen methods in
> HBASE-19033, I found that there maybe a hole in our CP hools. It is the in
> memory compaction.
>
> As Anoop suggested in HBASE-19001, we still need to give user the ability
> to extend the max versions and TTL config, so I plan to add back the hooks
> above to let CP users can change the max versions and TTL of a ScanInfo
> object. But I'm not sure whether in memory compaction will also discard
> expired cells, if so then we are in trouble...
>
> Thanks.
>
> 2017-10-25 6:03 GMT+08:00 Stack :
>
>> Chatting with my coworker Mr. Mike Drob, we were batting back and forth
>> what remains to be done. Surfacing our thoughts here so you all clued
>> inOr if you think otherwise, please speak up.
>>
>> We have ~13 issues to land:
>> https://issues.apache.org/jira/projects/HBASE/versions/12341594 About two
>> are meta-issues that are about process which leaves 11.
>>
>> Duo and Zheng Hu are to merge the FilterList fixes improvements
>> (HBASE-19057, HBASE-18410 et al.). These are blocker because some changed
>> API/semantic that we need to get out earlier rather than later.
>>
>> Once the above is merged, HBASE-13346, change of Filter method names to
>> mention Cell instead of KeyValue can land.
>>
>> HBASE-199048 needs a review (Anoop will probably do it), removing
>> IA.Private objects as params to MasterObserver... Hopefully this goes in
>> soon.
>>
>> Duo is hard at work on trackers for flush and compaction for CPs
>> (HBASE-18905). How is HBASE-19033 looking Duo (facility for Tephra)?
>>
>> I think HBASE-18906 (Phoenix Region#waitFor...) will evaporate after Duo
>> is
>> done w/ his work above.
>>
>> I'm on HBASE-18770 bypass and HBASE-19077 restore some parity after all
>> the
>> purges allowing CPs do direct calls against Regions in same Host.
>>
>> Anoop is on HBASE-19047 (Fixes) and Ram on cleanup of CellUtil.
>>
>> Another day or two?
>>
>> St.Ack
>>
>>
>>
>> On Mon, Oct 23, 2017 at 2:52 PM, Stack  wrote:
>>
>> >
>> > On Mon, Oct 23, 2017 at 11:59 AM, Josh Elser  wrote:
>> >
>> >> +1
>> >>
>> >> I was trying to work on helping out on the outstanding alpha-4 stuff
>> last
>> >> week -- will be continuing to try to do the same this week.
>> >>
>> >> If you need any help, Stack, or if others need reviews where I haven't
>> >> noticed on my own: feel free to @mention me.
>> >>
>> >>
>> > Thanks for the offer Josh. All items seem assigned and are being
>> actively
>> > worked on. If you get a moment, reviews by you (or anyone else) helps
>> move
>> > the process along.
>> >
>> > We need to merge in HBASE-18410 branch to pick up Filter improvements.
>> > Then HBASE-13346 can go in.
>> >
>> > You are already helping out on HBASE-18906, thanks. Looks like that will
>> > be addressed by other alpha-4s about to land.
>> >
>> > St.Ack
>> > TODOs: https://issues.apache.org/jira/projects/HBASE/versions/12341594
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >> On 10/23/17 12:53 PM, Stack wrote:
>> >>
>> >>> (Reviving this thread)
>> >>>
>> >>> Lets push out alpha-4 this week. Alpha-4 is the release that has the
>> >>> refactor of the Coprocessor API shutting down access to internals
>> marked
>> >>> InterfaceAudience.Private.
>> >>>
>> >>> The outstanding list is here:
>> >>> https://issues.apache.org/jira/projects/HBASE/versions/12341594
>> >>>
>> >>> Please push in anything marked alpha-4 that belongs to you.
>> >>>
>> >>> If issue, talk out loud on this thread. If you need a review to land
>> an
>> >>> item, shout on the issue and here; we'll help you out.
>> >>>
>> >>> As is, items are coming along nicely I'd say. We need to merge the
>> filter
>> >>> branch -- HBASE-18410 -- so APIs are finished for hbase2.
>> >>>
>> >>> Post alpha-4, we'll have to hunt down our downstreamers and help them
>> >>> test
>> >>> on top of alpha-4 so rolling into beta-1, we have confidence our
>> >>> downstreamers know what to expect (or we discover what we missed
>> BEFORE
>> >>> we
>> >>> beta-1).
>> >>>
>> >>> Thanks for time,
>> >>> S
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Sep 8, 2017 at 2:04 PM, Stack  wrote:
>> >>>
>> >>> I'll put up an alpha3 RC Monday, probably Monday night. That should be
>>  time, if we all sprint, for the public-facing API fixes to be done.
>> 
>>  I had a bunch of Coprocessor refactor and fixup scheduled for alpha3
>> but
>>  it is plain that more time is needed (in spite of valiant effort so
>> far
>>  by
>>  Anoop, Duo, Appy, etc.). Therefore, lets run a 2.0.0-alpha-4 whose
>>  theme is
>>  "Coprocessor Fixup". Hopefu

Re: [ANNOUNCE] New HBase committer Lars Francke

[OpenInx]

Congratulations.

On Thu, Oct 26, 2017 at 9:36 AM, 张铎(Duo Zhang) 
wrote:

> Congratulations!
>
> 2017-10-26 4:35 GMT+08:00 Esteban Gutierrez :
>
> > Congrats Lars F! well deserved!
> >
> > --
> > Cloudera, Inc.
> >
> >
> > On Wed, Oct 25, 2017 at 3:26 PM, Andrew Purtell 
> > wrote:
> >
> > > Congratulations and welcome!
> > >
> > >
> > > On Wed, Oct 25, 2017 at 12:56 PM, Lars George 
> > > wrote:
> > >
> > > > On behalf of the Apache HBase PMC, I am pleased to announce that Lars
> > > > Francke has accepted the PMC's invitation to become a committer on
> the
> > > > project.
> > > >
> > > > We appreciate all of Lars' great work thus far and look forward to
> > > > continued involvement.
> > > >
> > > > Please join me in congratulating LarsF! (Opting to use last name
> > > > initials as we now have three Lars' as committers)
> > > >
> > > > --
> > > > Best regards,
> > > > LarsG
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >- A23, Crosstalk
> > >
> >
>



-- 
==
Openinx  blog : http://openinx.github.io

TO BE A GREAT HACKER !
==

Re: Moving 2.0 forward

[Duo Zhang]

When adding back the pre(Flush/Compact/Store)ScannerOpen methods in
HBASE-19033, I found that there maybe a hole in our CP hools. It is the in
memory compaction.

As Anoop suggested in HBASE-19001, we still need to give user the ability
to extend the max versions and TTL config, so I plan to add back the hooks
above to let CP users can change the max versions and TTL of a ScanInfo
object. But I'm not sure whether in memory compaction will also discard
expired cells, if so then we are in trouble...

Thanks.

2017-10-25 6:03 GMT+08:00 Stack :

> Chatting with my coworker Mr. Mike Drob, we were batting back and forth
> what remains to be done. Surfacing our thoughts here so you all clued
> inOr if you think otherwise, please speak up.
>
> We have ~13 issues to land:
> https://issues.apache.org/jira/projects/HBASE/versions/12341594 About two
> are meta-issues that are about process which leaves 11.
>
> Duo and Zheng Hu are to merge the FilterList fixes improvements
> (HBASE-19057, HBASE-18410 et al.). These are blocker because some changed
> API/semantic that we need to get out earlier rather than later.
>
> Once the above is merged, HBASE-13346, change of Filter method names to
> mention Cell instead of KeyValue can land.
>
> HBASE-199048 needs a review (Anoop will probably do it), removing
> IA.Private objects as params to MasterObserver... Hopefully this goes in
> soon.
>
> Duo is hard at work on trackers for flush and compaction for CPs
> (HBASE-18905). How is HBASE-19033 looking Duo (facility for Tephra)?
>
> I think HBASE-18906 (Phoenix Region#waitFor...) will evaporate after Duo is
> done w/ his work above.
>
> I'm on HBASE-18770 bypass and HBASE-19077 restore some parity after all the
> purges allowing CPs do direct calls against Regions in same Host.
>
> Anoop is on HBASE-19047 (Fixes) and Ram on cleanup of CellUtil.
>
> Another day or two?
>
> St.Ack
>
>
>
> On Mon, Oct 23, 2017 at 2:52 PM, Stack  wrote:
>
> >
> > On Mon, Oct 23, 2017 at 11:59 AM, Josh Elser  wrote:
> >
> >> +1
> >>
> >> I was trying to work on helping out on the outstanding alpha-4 stuff
> last
> >> week -- will be continuing to try to do the same this week.
> >>
> >> If you need any help, Stack, or if others need reviews where I haven't
> >> noticed on my own: feel free to @mention me.
> >>
> >>
> > Thanks for the offer Josh. All items seem assigned and are being actively
> > worked on. If you get a moment, reviews by you (or anyone else) helps
> move
> > the process along.
> >
> > We need to merge in HBASE-18410 branch to pick up Filter improvements.
> > Then HBASE-13346 can go in.
> >
> > You are already helping out on HBASE-18906, thanks. Looks like that will
> > be addressed by other alpha-4s about to land.
> >
> > St.Ack
> > TODOs: https://issues.apache.org/jira/projects/HBASE/versions/12341594
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >> On 10/23/17 12:53 PM, Stack wrote:
> >>
> >>> (Reviving this thread)
> >>>
> >>> Lets push out alpha-4 this week. Alpha-4 is the release that has the
> >>> refactor of the Coprocessor API shutting down access to internals
> marked
> >>> InterfaceAudience.Private.
> >>>
> >>> The outstanding list is here:
> >>> https://issues.apache.org/jira/projects/HBASE/versions/12341594
> >>>
> >>> Please push in anything marked alpha-4 that belongs to you.
> >>>
> >>> If issue, talk out loud on this thread. If you need a review to land an
> >>> item, shout on the issue and here; we'll help you out.
> >>>
> >>> As is, items are coming along nicely I'd say. We need to merge the
> filter
> >>> branch -- HBASE-18410 -- so APIs are finished for hbase2.
> >>>
> >>> Post alpha-4, we'll have to hunt down our downstreamers and help them
> >>> test
> >>> on top of alpha-4 so rolling into beta-1, we have confidence our
> >>> downstreamers know what to expect (or we discover what we missed BEFORE
> >>> we
> >>> beta-1).
> >>>
> >>> Thanks for time,
> >>> S
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Sep 8, 2017 at 2:04 PM, Stack  wrote:
> >>>
> >>> I'll put up an alpha3 RC Monday, probably Monday night. That should be
>  time, if we all sprint, for the public-facing API fixes to be done.
> 
>  I had a bunch of Coprocessor refactor and fixup scheduled for alpha3
> but
>  it is plain that more time is needed (in spite of valiant effort so
> far
>  by
>  Anoop, Duo, Appy, etc.). Therefore, lets run a 2.0.0-alpha-4 whose
>  theme is
>  "Coprocessor Fixup". Hopefully we can put an alpha-4 up by the
> following
>  week.
> 
>  We should then be ready for beta (beta == no new features, no API
>  changes,
>  just fixes).
> 
>  Thanks,
>  St.Ack
> 
> 
>  On Thu, Aug 17, 2017 at 12:35 PM, Stack  wrote:
> 
>  I put up the hbase-2.0.0-alpha2 release candidate. Please vote on it.
> >
> > For hbase-2.0.0-alpha3, the theme is solidifying API. I hope to get a
> > release out in the next week or so.
> >
> > I did a weeding of 2.0.0 

Re: [ANNOUNCE] New HBase committer Lars Francke

[Duo Zhang]

Congratulations!

2017-10-26 4:35 GMT+08:00 Esteban Gutierrez :

> Congrats Lars F! well deserved!
>
> --
> Cloudera, Inc.
>
>
> On Wed, Oct 25, 2017 at 3:26 PM, Andrew Purtell 
> wrote:
>
> > Congratulations and welcome!
> >
> >
> > On Wed, Oct 25, 2017 at 12:56 PM, Lars George 
> > wrote:
> >
> > > On behalf of the Apache HBase PMC, I am pleased to announce that Lars
> > > Francke has accepted the PMC's invitation to become a committer on the
> > > project.
> > >
> > > We appreciate all of Lars' great work thus far and look forward to
> > > continued involvement.
> > >
> > > Please join me in congratulating LarsF! (Opting to use last name
> > > initials as we now have three Lars' as committers)
> > >
> > > --
> > > Best regards,
> > > LarsG
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >- A23, Crosstalk
> >
>

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

[Apekshit Sharma]

Any reason why we don't build both together?

On Wed, Oct 25, 2017 at 3:17 PM, Apekshit Sharma  wrote:

> Thanks for the quick reply Busbey. Let me work on fixing the includes list
> (HBASE-19089 ). Will
> come back here if more questions arise.
>
> --Appy
>
> 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.
>>
>> 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.
>>
>> 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
>>
>
>
>
> --
>
> -- Appy
>



-- 

-- Appy

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

[Apekshit Sharma]

Thanks for the quick reply Busbey. Let me work on fixing the includes list (
HBASE-19089 ). Will come
back here if more questions arise.

--Appy

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.
>
> 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.
>
> 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
>



-- 

-- Appy

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

[Sean Busbey]

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.

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.

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

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

[Apekshit Sharma]

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

[jira] [Created] (HBASE-19089) Fix the list of included moduleSets in src and binary tars

[Appy (JIRA)]

Appy created HBASE-19089:


 Summary: Fix the list of included moduleSets in src and binary tars
 Key: HBASE-19089
 URL: https://issues.apache.org/jira/browse/HBASE-19089
 Project: HBase
  Issue Type: Bug
Reporter: Appy
Assignee: Appy


List of moduleSets included in src.xml and hadoop-two-compat.xml differ quite a 
lot. Particularly, hadoop-two-compat.xml is missing quite a few modules.
The core issue is duplication of list. Let me try to get rid of it by using 
shaded list of includes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [ANNOUNCE] New HBase committer Lars Francke

[Esteban Gutierrez]

Congrats Lars F! well deserved!

--
Cloudera, Inc.


On Wed, Oct 25, 2017 at 3:26 PM, Andrew Purtell  wrote:

> Congratulations and welcome!
>
>
> On Wed, Oct 25, 2017 at 12:56 PM, Lars George 
> wrote:
>
> > On behalf of the Apache HBase PMC, I am pleased to announce that Lars
> > Francke has accepted the PMC's invitation to become a committer on the
> > project.
> >
> > We appreciate all of Lars' great work thus far and look forward to
> > continued involvement.
> >
> > Please join me in congratulating LarsF! (Opting to use last name
> > initials as we now have three Lars' as committers)
> >
> > --
> > Best regards,
> > LarsG
> >
>
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [ANNOUNCE] New HBase committer Lars Francke

[Andrew Purtell]

Congratulations and welcome!


On Wed, Oct 25, 2017 at 12:56 PM, Lars George  wrote:

> On behalf of the Apache HBase PMC, I am pleased to announce that Lars
> Francke has accepted the PMC's invitation to become a committer on the
> project.
>
> We appreciate all of Lars' great work thus far and look forward to
> continued involvement.
>
> Please join me in congratulating LarsF! (Opting to use last name
> initials as we now have three Lars' as committers)
>
> --
> Best regards,
> LarsG
>



-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [DISCUSS] Help adding a check for localization edge cases in our current test suites?

[Sean Busbey]

I don't think so.

On Oct 25, 2017 2:48 PM, "Mike Drob"  wrote:

> Was there ever a JIRA filed for this? I have some ideas on how we can
> implement it...
>
> On Wed, Oct 18, 2017 at 9:48 PM, 张铎(Duo Zhang) 
> wrote:
>
> > File an issue and post what to do there? I think there are plenty of
> > Chinese contributors in our community, although some of them may also use
> > English locale :)
> >
> > 2017-10-18 22:57 GMT+08:00 Sean Busbey :
> >
> > > Hi folks!
> > >
> > > This comment from Chia-Ping on HBASE-19020 has me thinking:
> > >
> > > > The TestXmlParsing is a flaky test in my jenkins, because the error
> > > message from my machine is in Chinese.
> > >
> > > I wonder how many more of our tests rely incorrectly on the
> > > localization settings being set to American English.
> > >
> > > Would any of our folks who normally work with a locale that isn't
> > > American English be willing to help me get a test set up (maybe in our
> > > nightly runs?) that tries to catch these kinds of issues?
> > >
> >
>

[ANNOUNCE] New HBase committer Lars Francke

[Lars George]

On behalf of the Apache HBase PMC, I am pleased to announce that Lars
Francke has accepted the PMC's invitation to become a committer on the
project.

We appreciate all of Lars' great work thus far and look forward to
continued involvement.

Please join me in congratulating LarsF! (Opting to use last name
initials as we now have three Lars' as committers)

--
Best regards,
LarsG

Re: [DISCUSS] Help adding a check for localization edge cases in our current test suites?

[Mike Drob]

Was there ever a JIRA filed for this? I have some ideas on how we can
implement it...

On Wed, Oct 18, 2017 at 9:48 PM, 张铎(Duo Zhang) 
wrote:

> File an issue and post what to do there? I think there are plenty of
> Chinese contributors in our community, although some of them may also use
> English locale :)
>
> 2017-10-18 22:57 GMT+08:00 Sean Busbey :
>
> > Hi folks!
> >
> > This comment from Chia-Ping on HBASE-19020 has me thinking:
> >
> > > The TestXmlParsing is a flaky test in my jenkins, because the error
> > message from my machine is in Chinese.
> >
> > I wonder how many more of our tests rely incorrectly on the
> > localization settings being set to American English.
> >
> > Would any of our folks who normally work with a locale that isn't
> > American English be willing to help me get a test set up (maybe in our
> > nightly runs?) that tries to catch these kinds of issues?
> >
>

Re: [NOTICE] possible cause of recent poor build quality on builds.a.o

[Sean Busbey]

And now there's a jira:

HDFS-12711

On Wed, Oct 25, 2017 at 12:42 AM, Sean Busbey  wrote:
> sure here's the hadoop thread:
>
> https://s.apache.org/azOi
>
> On Wed, Oct 25, 2017 at 12:20 AM, Chia-Ping Tsai  wrote:
>> Could you share the reference to the  hdfs changes or discussion?
>>
>> On 2017-10-25 02:06, Sean Busbey  wrote:
>>> hi folks!
>>>
>>> FYI, the Hadoop folks have identified that some recent changes to HDFS
>>> have been eating all memory on hosts where their tests run. So that
>>> might be the culprit in our recent spat of new odd looking surefire
>>> failures.
>>>
>>> Yetus is working to add in some guard rails to keep Hadoop from doing
>>> this in the future:
>>>
>>> https://issues.apache.org/jira/browse/YETUS-561
>>>
>>> Related, I have a temporary measure in place on our precommit runs
>>> that grabs a bunch of machine information (cpus, memory, disks, etc).
>>> If you look at build artifacts they'll be in a directory named
>>> 'machine' under 'patchprocess'.
>>>

Re: Branch 1.4 update

[Andrew Purtell]

Now that HBASE-15631 has been committed I plan to roll 1.4.0 RC0 this week.
Right now I am looking at a few unit tests that are infrequent flakes and
have been on branch-1 and branch-1.4 for a while.



On Wed, Oct 4, 2017 at 2:23 PM, Andrew Purtell  wrote:

> I had hoped to make a release candidate of 1.4.0 a long time ago when I
> first made the branch, but work/life intervened. Sorry it has been slow
> going.
>
> I've been making some test fixes to shore up unit test suite results.
>
> As far as big items, at this point a candidate 1.4.0 is only waiting on
> HBASE-15631 (https://reviews.apache.org/r/60672/). I had to go away for
> work for a while but am now back pushing that forward. For me as branch-1.4
> RM regionserver assignment groups is the must have feature for the 1.4 code
> line. If anyone has a strong feeling against this, let's discuss it now. I
> have asked before and I believe there are no objections to doing the
> backport because the functional changes are entirely contained to the new
> hbase-rsgroups module.
>
> Once HBASE-15631 is resolved I will be able to make a RC. This should be
> soon. I've addressed all of the review feedback up on RB and anticipate
> only minor additional changes to fix any issues discovered during unit and
> cluster testing.
>
> --
> Best regards,
> Andrew
>
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

[Josh Elser]

:) no worries, Appy. These are good questions.

It really comes down to the question: would HBase ever provide multiple 
metrics implementations for users?


As we know metrics in HBase now, there isn't any reason to support 
multiple implementations of metrics. We have one implementation which is 
optimal for people to use.


One plausible use-case I can see being built is a metrics implementation 
that natively uses something _other than_ Hadoop metrics2. Something you 
may not have seen yet is the translation-layer from Dropwizard Metrics 
to Metrics2 via HBaseMetrics2HadoopMetricsAdapter.java.


I could see a world where folks would want to build an integration with 
metrics-library1 to support the metrics platform for their $business1. 
$business2 might want to use metrics-library2 that can automatically 
push to something. As we know all too well, there may be conflicting 
dependencies between metrics-library1 and metrics-library2 to prevent 
them from successfully functioning on the classpath at the same time. 
Additionally, $business1 may have a hard requirement to not deploy 
metrics-library2 (and vice versa). One final concern, bundling our 
"default" DropwizardMetrics 3-based implementation could cause headaches 
for users who want to build their own metrics-api implementation.


Granted, all of the above is hypothetical, but I think leaving this 
flexibility in place is worth the separation of logic.


On 10/25/17 3:35 AM, Apekshit Sharma wrote:

Hi Josh

You're right that naming doesn't make it clear, but Enis added a really
great description in README of hbase-metrics-api to explain what's in each
module. However it's not obvious why are we splitting things into separate
module, as opposed to say, separating implementation in a separate "sub"
package.

I don't know Avatica, but as you clearly state, one of the requirements was
being able to plug in different implementations. Using service provider
clearly makes sense in that case, so does keeping the implementation in a
separate jar to avoid loading it if not needed.
But in case of HBase, even if we have multiple implementations
(hypothetically, because it doesn't seem probable), since the only user
will be HBase and all modules will always be in classpath, it doesn't
really get us anything. Right?
I dug into this code first time today and just learnt about service
providers, so i may be off, in which case please correct me. Thank you!

On Tue, Oct 24, 2017 at 8:25 PM, Josh Elser  wrote:


Hey Appy,

I think Enis essentially copied what I was originally trying to do. Up in
Avatica[1], I made a similar API Maven module which just had interfaces.
The implementation was them split up into a different module to avoid the
implementation details of the API (specifically, using Dropwizard3) from
"infecting" anyone who just wanted the API. Implementations of the metrics
API could be picked up via ServiceLoader.

So, here in HBase, our "hbase-metrics" module is really an implementation
of hbase-metrics-api for dropwizard-metrics 3.2.1 (the naming just loses
that detail).

In Avatica, I wanted to make sure that people could use a metrics library
implementation of their choosing (e.g. tied to whatever kind of container
or app-server you're deploying Avatica). In HBase, that isn't such a
concern -- we publish via Metrics2 and that's it.

That said, I could see a place where this separation enables some extra
functionality with less headache, but I, admittedly, don't have a concrete
use-case behind it.

- Josh

[1] https://github.com/apache/calcite-avatica

On 10/24/17 6:09 PM, Apekshit Sharma wrote:


Hi

Am confused why do we have this weird circular dependency between the two
modules: hbase-metrics-api & hbase-metrics. And since maven doesn't allow
it explicitly, this was tucked and hidden by using reflection?

MetricRegistriesImpl[hbase-metrics] implements
MetricRegistries[hbase-metrics-api].
MetricRegistriesLoader[hbase-metrics-api] depends on this implementation,
MetricRegistriesImpl, because it instantiates it via reflection

[1].

Can we just move all interfaces and default implementation together into
single module. But i like the idea of keeping implementations in separate
package with "impl" explicitly in package name.

[1]
https://github.com/apache/hbase/blob/eee3b0180ead73c09b33f95
83bfee9c01bc3aed2/hbase-metrics-api/src/main/java/org/
apache/hadoop/hbase/metrics/MetricRegistriesLoader.java#L39

-- Appy

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

[Elliott Clark]

That issue renamed a bunch of what used to be there only for
hbase-hadoop-compat. HBASE-6405 is the start of the chain.

Currently though I don't see any reason for them to be in separate modules
unless we think hadoop will make another breaking change to the metrics
classes.


On Tue, Oct 24, 2017 at 7:38 PM, Apekshit Sharma  wrote:

> Hey Elliott, good to see you around :)
>
> Btw, this is new stuff added in HBASE-9774 which was committed to only 2.0.
> Made it to 1.4 too later (HBASE-18060).
>
> -- Appy
>
> On Tue, Oct 24, 2017 at 4:16 PM, Elliott Clark  wrote:
>
> > The weird module dance with reflection came from needing to extend inner
> > hadoop classes on multiple different versions. This was back when HBase
> had
> > to support hadoop < 1, hadoop 1.x, and hadoop 2.x. When we dropped older
> > hadoop versions then things got easier.
> >
> > On Tue, Oct 24, 2017 at 3:09 PM, Apekshit Sharma 
> > wrote:
> >
> > > Hi
> > >
> > > Am confused why do we have this weird circular dependency between the
> two
> > > modules: hbase-metrics-api & hbase-metrics. And since maven doesn't
> allow
> > > it explicitly, this was tucked and hidden by using reflection?
> > >
> > > MetricRegistriesImpl[hbase-metrics] implements
> > > MetricRegistries[hbase-metrics-api].
> > > MetricRegistriesLoader[hbase-metrics-api] depends on this
> > implementation,
> > > MetricRegistriesImpl, because it instantiates it via reflection
> > >  > > c01bc3aed2/hbase-metrics-api/src/main/java/org/apache/
> > > hadoop/hbase/metrics/MetricRegistriesLoader.java#L39>
> > > [1].
> > >
> > > Can we just move all interfaces and default implementation together
> into
> > > single module. But i like the idea of keeping implementations in
> separate
> > > package with "impl" explicitly in package name.
> > >
> > > [1]
> > > https://github.com/apache/hbase/blob/eee3b0180ead73c09b33f9583bfee9
> > > c01bc3aed2/hbase-metrics-api/src/main/java/org/apache/
> > > hadoop/hbase/metrics/MetricRegistriesLoader.java#L39
> > >
> > > -- Appy
> > >
> >
>
>
>
> --
>
> -- Appy
>

[jira] [Resolved] (HBASE-18410) FilterList Improvement.

[Duo Zhang (JIRA)]

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

Duo Zhang resolved HBASE-18410.
---
  Resolution: Fixed
Hadoop Flags: Incompatible change,Reviewed  (was: Incompatible change)

Merged into master and cherry-picked to branch-2.

Thanks all for the nice work.

> FilterList  Improvement. 
> -
>
> Key: HBASE-18410
> URL: https://issues.apache.org/jira/browse/HBASE-18410
> Project: HBase
>  Issue Type: Umbrella
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
> Fix For: 2.0.0-alpha-4
>
>
> FilterList.java is complex now, and we have found some improvements for it.  
> So create an issue to address it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [DISCUSS] Merge FilterList Improvement - Branch HBASE-18410

[Duo Zhang]

+1. Just done another round of rebase and force push, it is clean. Let me
do the merge now.

Thanks all for taking care of this.

2017-10-25 11:26 GMT+08:00 Josh Elser :

> +1 IMO, go for it -- enough eyes have been had on the last little bit.
>
>
> On 10/24/17 11:05 PM, stack wrote:
>
>> The boys are almost ready to merge. They were going to run a VOTE. I told
>> them not to bother. There is enough support behind the merge they don't
>> need a vote IMO. If you think otherwise, speak up.
>>
>> Thanks,
>>
>> St.Ack
>> P.S. Release note on HBASE-18410 will have summary of changes that come in
>> on the merge. Thanks.
>>
>> On Sat, Oct 21, 2017 at 6:37 PM, stack  wrote:
>>
>> +1 on merge then sorting out the mess. I want to include this stuff in
>>> alpha 4.
>>>
>>> Thanks,
>>> S
>>>
>>> On Oct 20, 2017 01:18, "OpenInx"  wrote:
>>>
>>> Fine,  I opened jira HBASE-19057 for it.

 On Fri, Oct 20, 2017 at 4:13 PM, Anoop John 
 wrote:

 +1 for opening an issue and handle the merge as part of that.
> I did a review of the new classes for the FilterList impl..  Great
> cleanup work.  Very easy to read and understand the code now..
> Have few comments specially on FilterListWithOR.   If u can raise a
> merge issue, can comment down that.  If needed can open up subtasks
> can then handle.
>
> -Anoop-
>
> On Fri, Oct 20, 2017 at 12:01 PM, 张铎(Duo Zhang)  >
> wrote:
>
>> Open a issue to track the merging work? Let's do a rebase and more
>>
> testing
>
>> in that issue. And then come back and open a vote.
>>
>> 2017-10-20 11:48 GMT+08:00 OpenInx :
>>
>>   I believe there are several UTs which we want them to be the

>>> guard of

> merging?
>>> What is the situation of these UTs?
>>>
>>> The UT is TestFilterListOnMini which make sure the filter list with
>>>
>> family
>
>> filter in it works fine,  it's enable in branch HBASE-18410 now .
>>>
>> see

> https://issues.apache.org/jira/browse/HBASE-18977.
>>>
>>> Some of recent patches, such as HBASE-18368-HBASE-18410.v2.patch,

>>> didn't get
>>> proper QA run
>>>
>>> All of the UT passed except one failed case , and this failed case is
>>> unrelated.   see
>>> https://builds.apache.org/job/PreCommit-HBASE-Build/9157/testReport/
>>>
>>> This is a incompatible change for filter developer ?

>>>
>>> Yes, I think so.
>>>
>>>
>>>
>>>
>>> On Fri, Oct 20, 2017 at 9:37 AM, Guanghao Zhang 
>>> wrote:
>>>
>>> HBASE-18368-HBASE-18410.v2.patch got a proper QA
 run: PreCommit-HBASE-Build/9157. And the failed ut is not related.

>>> So

> I
>
>> committed it to branch HBASE-18410...
 HBASE-18368 changed the javadoc of NEXT_ROW. This is a incompatible

>>> change
>>>
 for filter developer?

 2017-10-20 9:14 GMT+08:00 Ted Yu :

 Some of recent patches, such as HBASE-18368-HBASE-18410.v2.pat
>
 ch,

> didn't
>>>
 get proper QA run (due to precommit disruption).
>
> We'd better get several good QA runs.
>
> Cheers
>
> On Thu, Oct 19, 2017 at 5:38 PM, 张铎(Duo Zhang) <
>
 palomino...@gmail.com>
>
>> wrote:
>
> I believe there are several UTs which we want them to be the
>>
> guard of
>
>> merging? What is the situation of these UTs?
>>
>> Thanks.
>>
>> 2017-10-20 8:33 GMT+08:00 OpenInx :
>>
>> Hi All :
>>>
>>>
>>> All subtasks have been resolved except HBASE-18993
>>> , I think
>>>
>> it's
>
>> time

> to
>>
>>> merge HBASE-18410 >>
>> jira/browse/HBASE-18410
>>>

> branch
>>> to master now.
>>>
>>> Any concerns ?
>>>
>>> Thanks.
>>>
>>>
>>
>

>>>
>>>
>>> --
>>> ==
>>> Openinx  blog : http://openinx.github.io
>>>
>>> TO BE A GREAT HACKER !
>>> ==
>>>
>>>
>


 --
 ==
 Openinx  blog : http://openinx.github.io

 TO BE A GREAT HACKER !
 ==


>>>
>>

[jira] [Created] (HBASE-19088) move_tables_rsgroup will throw an exception when the table is disabled

[Guangxu Cheng (JIRA)]

Guangxu Cheng created HBASE-19088:
-

 Summary: move_tables_rsgroup will throw an exception when the 
table is disabled
 Key: HBASE-19088
 URL: https://issues.apache.org/jira/browse/HBASE-19088
 Project: HBase
  Issue Type: Bug
  Components: rsgroup
Affects Versions: 3.0.0
Reporter: Guangxu Cheng
Assignee: Guangxu Cheng



When the table is disabled, *move_tables_rsgroup* will throw an exception, but 
the table has been moved to the new group successfully.

{code:java}
hbase(main):009:0> move_tables_rsgroup 'default',['t1']
ERROR: java.io.IOException
at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:465)
at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:134)
at 
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:325)
at 
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:305)
Caused by: java.lang.NullPointerException
at 
org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProcedureProtos$MoveRegionStateData$Builder.setSourceServer(MasterProcedureProtos.java:26022)
at 
org.apache.hadoop.hbase.master.assignment.MoveRegionProcedure.serializeStateData(MoveRegionProcedure.java:133)
at 
org.apache.hadoop.hbase.procedure2.ProcedureUtil.convertToProtoProcedure(ProcedureUtil.java:198)
at 
org.apache.hadoop.hbase.procedure2.store.wal.ProcedureWALFormat.writeEntry(ProcedureWALFormat.java:211)
at 
org.apache.hadoop.hbase.procedure2.store.wal.ProcedureWALFormat.writeInsert(ProcedureWALFormat.java:222)
at 
org.apache.hadoop.hbase.procedure2.store.wal.WALProcedureStore.insert(WALProcedureStore.java:470)
at 
org.apache.hadoop.hbase.procedure2.ProcedureExecutor.submitProcedure(ProcedureExecutor.java:866)
at 
org.apache.hadoop.hbase.procedure2.ProcedureExecutor.submitProcedure(ProcedureExecutor.java:835)
at 
org.apache.hadoop.hbase.master.procedure.ProcedureSyncWait.submitAndWaitProcedure(ProcedureSyncWait.java:120)
at 
org.apache.hadoop.hbase.master.assignment.AssignmentManager.move(AssignmentManager.java:557)
at 
org.apache.hadoop.hbase.rsgroup.RSGroupAdminServer.moveTables(RSGroupAdminServer.java:413)
at 
org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint$RSGroupAdminServiceImpl.moveTables(RSGroupAdminEndpoint.java:190)
at 
org.apache.hadoop.hbase.protobuf.generated.RSGroupAdminProtos$RSGroupAdminService.callMethod(RSGroupAdminProtos.java:12786)
at 
org.apache.hadoop.hbase.master.MasterRpcServices.execMasterService(MasterRpcServices.java:786)
at 
org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java)
at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
... 3 more

Reassign tables from one RegionServer group to another.

Example:

  hbase> move_tables_rsgroup 'dest',['table1','table2']


Took 0.0297 seconds
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19087) Remove redundant characters from the audit log

[Guangxu Cheng (JIRA)]

Guangxu Cheng created HBASE-19087:
-

 Summary: Remove redundant characters from the audit log
 Key: HBASE-19087
 URL: https://issues.apache.org/jira/browse/HBASE-19087
 Project: HBase
  Issue Type: Bug
Affects Versions: 3.0.0, 2.0.0-alpha-4
Reporter: Guangxu Cheng
Assignee: Guangxu Cheng


After HBASE-18878, the audit log contains redundant characters "Optional" which 
leading to unreadable
{code:java}
2017-10-19 19:51:08,054 INFO  
[RpcServer.default.FPBQ.Fifo.handler=49,queue=4,port=8081] master.HMaster: 
Client=Optional[username]/Optional[/locahost] disable tablename 
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19086) Unify all format of external URL link in our HBase boook(asciidoc file)

[Yung-An He (JIRA)]

Yung-An He created HBASE-19086:
--

 Summary: Unify all  format of external URL link in our HBase 
boook(asciidoc file)
 Key: HBASE-19086
 URL: https://issues.apache.org/jira/browse/HBASE-19086
 Project: HBase
  Issue Type: Improvement
  Components: documentation
Reporter: Yung-An He
Assignee: Yung-An He
Priority: Minor
 Fix For: 2.0.0


Unify all format of external URL link to 
{code:none}
link:http://www.example.com[example link]
{code}

If the URL link relates about http://.apache.org, the format is below:
{code:none}
link://.apache.org[apache.org]
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

[Apekshit Sharma]

Hi Josh

You're right that naming doesn't make it clear, but Enis added a really
great description in README of hbase-metrics-api to explain what's in each
module. However it's not obvious why are we splitting things into separate
module, as opposed to say, separating implementation in a separate "sub"
package.

I don't know Avatica, but as you clearly state, one of the requirements was
being able to plug in different implementations. Using service provider
clearly makes sense in that case, so does keeping the implementation in a
separate jar to avoid loading it if not needed.
But in case of HBase, even if we have multiple implementations
(hypothetically, because it doesn't seem probable), since the only user
will be HBase and all modules will always be in classpath, it doesn't
really get us anything. Right?
I dug into this code first time today and just learnt about service
providers, so i may be off, in which case please correct me. Thank you!

On Tue, Oct 24, 2017 at 8:25 PM, Josh Elser  wrote:

> Hey Appy,
>
> I think Enis essentially copied what I was originally trying to do. Up in
> Avatica[1], I made a similar API Maven module which just had interfaces.
> The implementation was them split up into a different module to avoid the
> implementation details of the API (specifically, using Dropwizard3) from
> "infecting" anyone who just wanted the API. Implementations of the metrics
> API could be picked up via ServiceLoader.
>
> So, here in HBase, our "hbase-metrics" module is really an implementation
> of hbase-metrics-api for dropwizard-metrics 3.2.1 (the naming just loses
> that detail).
>
> In Avatica, I wanted to make sure that people could use a metrics library
> implementation of their choosing (e.g. tied to whatever kind of container
> or app-server you're deploying Avatica). In HBase, that isn't such a
> concern -- we publish via Metrics2 and that's it.
>
> That said, I could see a place where this separation enables some extra
> functionality with less headache, but I, admittedly, don't have a concrete
> use-case behind it.
>
> - Josh
>
> [1] https://github.com/apache/calcite-avatica
>
> On 10/24/17 6:09 PM, Apekshit Sharma wrote:
>
>> Hi
>>
>> Am confused why do we have this weird circular dependency between the two
>> modules: hbase-metrics-api & hbase-metrics. And since maven doesn't allow
>> it explicitly, this was tucked and hidden by using reflection?
>>
>> MetricRegistriesImpl[hbase-metrics] implements
>> MetricRegistries[hbase-metrics-api].
>> MetricRegistriesLoader[hbase-metrics-api] depends on this implementation,
>> MetricRegistriesImpl, because it instantiates it via reflection
>> > 583bfee9c01bc3aed2/hbase-metrics-api/src/main/java/org/
>> apache/hadoop/hbase/metrics/MetricRegistriesLoader.java#L39>
>> [1].
>>
>> Can we just move all interfaces and default implementation together into
>> single module. But i like the idea of keeping implementations in separate
>> package with "impl" explicitly in package name.
>>
>> [1]
>> https://github.com/apache/hbase/blob/eee3b0180ead73c09b33f95
>> 83bfee9c01bc3aed2/hbase-metrics-api/src/main/java/org/
>> apache/hadoop/hbase/metrics/MetricRegistriesLoader.java#L39
>>
>> -- Appy
>>
>>


-- 

-- Appy