Re: [DISCUSS] Becoming a Committer

[Zach York]

bq. As a
relatively new member in the HBase community and a non-committer, once the
new member decides that he/ she wants to become a Committer, it will be
helpful to have a list of PMC members that he/ she can communicate with and
get feedback from time to time. Feedback may include potential adjustments
and rough idea about progress towards the goal.

This sounds like a good idea! Ideally, if you interact with the community
often enough, you should be building connections, but it nevers hurts to
have someone to check how they perceive your work.

bq. For others, having
this list of volunteer mentors, will surely help.

Again I agree. This part is especially important as it is hard to judge
your progress if you don't have someone at the same company to converse
with.

On Fri, Sep 22, 2017 at 3:38 PM, Umesh Agashe  wrote:

> Hi,
>
> Thank you all for a good discussion here. Issues with both having and NOT
> having documented specific criteria are well articulated here. As a
> relatively new member in the HBase community and a non-committer, once the
> new member decides that he/ she wants to become a Committer, it will be
> helpful to have a list of PMC members that he/ she can communicate with and
> get feedback from time to time. Feedback may include potential adjustments
> and rough idea about progress towards the goal. Paid professionals who are
> working with PMC members, can talk to their colleagues. For others, having
> this list of volunteer mentors, will surely help. IMHO, this will make
> process a bit more transparent. I would like to know your thoughts on this.
>
> Thanks,
> Umesh
>
>
>
>
> On Thu, Sep 21, 2017 at 1:41 PM, Misty Stanley-Jones 
> wrote:
>
> > I feel like I inject this note into all discussions like this, but I'm
> > going to do it again. "Act like a committer" does not ONLY mean to
> produce
> > code for HBase. It means to support the project. This may mean any of the
> > following, plus a long list of other things I'm sure I'm not thinking of
> > right now:
> >
> > - Contribute to the docs (yay!)
> > - Help fix and improve testing
> > - Participate in release candidate votes, even if non-binding
> > - Review other people's work
> > - Help newbies
> > - Answer questions
> > - Update the website
> > - File issues
> > - Mentor new contributors of all sorts
> > - Give talks about HBase
> > - Write blogs about HBase
> > - Participate in design discussions
> > - Provide UX feedback
> > - Write demo applications
> > - Help us attract and retain a diverse community
> > - Interact with other projects in ways that benefit HBase and those other
> > projects
> >
> > I would personally consider all of these bullet points to be super
> > significant in "act like a committer" type discussions. I think that
> > contributing code is only one aspect. For some reason it seems to be the
> > most appealing aspect to lots of people, but IMHO that makes for a poor
> > community experience.
> >
> > On Wed, Sep 20, 2017 at 11:48 AM, Mike Drob  wrote:
> >
> > >  Hi folks,
> > >
> > > I've been chatting with folks off and on about this for a while, and
> was
> > > told that this made sense as a discussion on the dev@ list.
> > >
> > > How does the PMC select folks for committership? The most common answer
> > is
> > > that folks should 'act like a committer' but that's painfully nebulous
> > and
> > > easy to get sidetracked onto other topics. The problem is compounded
> > > because what may be great on one project is inconsistently applied on
> > other
> > > projects in the ASF, and yet we are all very tightly coupled as
> > communities
> > > and as project dependencies.
> > >
> > > Ideally, this is something that we can document in the book. Misty
> gently
> > > pointed out http://hbase.apache.org/book.html#_guide_for_hbase_
> > committers
> > > but
> > > also noted that it's for what happens after somebody becomes a
> committer.
> > > Still, if the standard is "act like one until you become one" then it's
> > > useful reading for people. Also, there doesn't seem to be any
> guidelines
> > > like this for PMC.
> > >
> > > Is the list of prerequisites possible to articulate, or will it always
> > boil
> > > down to "intangibles?" Is there a concern that providing a checklist
> > > (perhaps a list of items necessary, but not sufficient) will lead to
> > folks
> > > motivated wrongly, similar to oft maligned "resume driven development?"
> > >
> > > I'll kick off the discussion by saying that my personal yardstick of
> > "Can I
> > > trust this person's judgement regarding code/reviews" is probably too
> > vague
> > > to be useful, and even worse is impossible for others to apply.
> > >
> > > Curiously,
> > > Mike
> > >
> >
>

Re: Please congratulate our new PMC Chair Misty Stanley-Jones

[Umesh Agashe]

Congratulations Misty!



On Fri, Sep 22, 2017 at 11:41 AM, Esteban Gutierrez 
wrote:

> Thats awesome! Congratulations, Misty!
>
>
>
> --
> Cloudera, Inc.
>
>
> On Fri, Sep 22, 2017 at 11:27 AM, Alexander Leblang <
> alex.lebl...@cloudera.com> wrote:
>
> > Congrats Misty! Well done!
> > On Fri, Sep 22, 2017 at 11:25 AM Wei-Chiu Chuang 
> > wrote:
> >
> > > Congrats! Misty!!
> > >
> > > On Fri, Sep 22, 2017 at 7:50 AM, Jimmy Xiang  wrote:
> > >
> > > > Congrats! Misty!!
> > > >
> > > > On Fri, Sep 22, 2017 at 7:16 AM, Pankaj kr 
> > wrote:
> > > >
> > > > > Congratulations Misty..!! :)
> > > > >
> > > > >
> > > > > -Pankaj-
> > > > >
> > > > >
> > > > > -Original Message-
> > > > > From: Andrew Purtell [mailto:apurt...@apache.org]
> > > > > Sent: Friday, September 22, 2017 3:08 AM
> > > > > To: dev@hbase.apache.org; u...@hbase.apache.org
> > > > > Subject: Please congratulate our new PMC Chair Misty Stanley-Jones
> > > > >
> > > > > At today's meeting of the Board, Special Resolution B changing the
> > > HBase
> > > > > project Chair to Misty Stanley-Jones was passed unanimously.
> > > > >
> > > > > Please join me in congratulating Misty on her new role!
> > > > >
> > > > > ​(If you need any help or advice please don't hesitate to ping me,
> > > Misty,
> > > > > but I suspect you'll do just fine and won't need it.)​
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Andrew
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > A very happy Hadoop contributor
> > >
> >
>

Re: [DISCUSS] Becoming a Committer

[Umesh Agashe]

Hi,

Thank you all for a good discussion here. Issues with both having and NOT
having documented specific criteria are well articulated here. As a
relatively new member in the HBase community and a non-committer, once the
new member decides that he/ she wants to become a Committer, it will be
helpful to have a list of PMC members that he/ she can communicate with and
get feedback from time to time. Feedback may include potential adjustments
and rough idea about progress towards the goal. Paid professionals who are
working with PMC members, can talk to their colleagues. For others, having
this list of volunteer mentors, will surely help. IMHO, this will make
process a bit more transparent. I would like to know your thoughts on this.

Thanks,
Umesh




On Thu, Sep 21, 2017 at 1:41 PM, Misty Stanley-Jones 
wrote:

> I feel like I inject this note into all discussions like this, but I'm
> going to do it again. "Act like a committer" does not ONLY mean to produce
> code for HBase. It means to support the project. This may mean any of the
> following, plus a long list of other things I'm sure I'm not thinking of
> right now:
>
> - Contribute to the docs (yay!)
> - Help fix and improve testing
> - Participate in release candidate votes, even if non-binding
> - Review other people's work
> - Help newbies
> - Answer questions
> - Update the website
> - File issues
> - Mentor new contributors of all sorts
> - Give talks about HBase
> - Write blogs about HBase
> - Participate in design discussions
> - Provide UX feedback
> - Write demo applications
> - Help us attract and retain a diverse community
> - Interact with other projects in ways that benefit HBase and those other
> projects
>
> I would personally consider all of these bullet points to be super
> significant in "act like a committer" type discussions. I think that
> contributing code is only one aspect. For some reason it seems to be the
> most appealing aspect to lots of people, but IMHO that makes for a poor
> community experience.
>
> On Wed, Sep 20, 2017 at 11:48 AM, Mike Drob  wrote:
>
> >  Hi folks,
> >
> > I've been chatting with folks off and on about this for a while, and was
> > told that this made sense as a discussion on the dev@ list.
> >
> > How does the PMC select folks for committership? The most common answer
> is
> > that folks should 'act like a committer' but that's painfully nebulous
> and
> > easy to get sidetracked onto other topics. The problem is compounded
> > because what may be great on one project is inconsistently applied on
> other
> > projects in the ASF, and yet we are all very tightly coupled as
> communities
> > and as project dependencies.
> >
> > Ideally, this is something that we can document in the book. Misty gently
> > pointed out http://hbase.apache.org/book.html#_guide_for_hbase_
> committers
> > but
> > also noted that it's for what happens after somebody becomes a committer.
> > Still, if the standard is "act like one until you become one" then it's
> > useful reading for people. Also, there doesn't seem to be any guidelines
> > like this for PMC.
> >
> > Is the list of prerequisites possible to articulate, or will it always
> boil
> > down to "intangibles?" Is there a concern that providing a checklist
> > (perhaps a list of items necessary, but not sufficient) will lead to
> folks
> > motivated wrongly, similar to oft maligned "resume driven development?"
> >
> > I'll kick off the discussion by saying that my personal yardstick of
> "Can I
> > trust this person's judgement regarding code/reviews" is probably too
> vague
> > to be useful, and even worse is impossible for others to apply.
> >
> > Curiously,
> > Mike
> >
>

support for zero copy reads

[Jan Kunigk]

Hi, does HBase take advantage of HDFS zero copy reads?
My idea is that RegionServers could potentially mmap everything they need
via the HDFS ZCR API and pass SKIP_CHECKSUMS when reading files via mmap,
since HBase supports its own checksumming on the HFile level... correct?

Could be completely wrong... Hence the open question.

J

[jira] [Created] (HBASE-18867) maven enforcer plugin needs update to work with jdk9

[Sean Busbey (JIRA)]

Sean Busbey created HBASE-18867:
---

 Summary: maven enforcer plugin needs update to work with jdk9
 Key: HBASE-18867
 URL: https://issues.apache.org/jira/browse/HBASE-18867
 Project: HBase
  Issue Type: Sub-task
  Components: build
Affects Versions: 2.0.0-alpha-3
Reporter: Sean Busbey
Assignee: Sean Busbey
Priority: Blocker


build fails under jdk9, even when targeting java 8

{code}

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.4:enforce 
(min-maven-min-java-banned-xerces) on project hbase: Execution 
min-maven-min-java-banned-xerces of goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.4:enforce failed: An API 
incompatibility was encountered while executing 
org.apache.maven.plugins:maven-enforcer-plugin:1.4:enforce: 
java.lang.ExceptionInInitializerError: null
[ERROR] -
[ERROR] realm =plugin>org.apache.maven.plugins:maven-enforcer-plugin:1.4
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = 
file:/Users/busbey/.m2/repository/org/apache/maven/plugins/maven-enforcer-plugin/1.4/maven-enforcer-plugin-1.4.jar
[ERROR] urls[1] = 
file:/Users/busbey/.m2/repository/org/codehaus/mojo/extra-enforcer-rules/1.0-beta-6/extra-enforcer-rules-1.0-beta-6.jar
[ERROR] urls[2] = 
file:/Users/busbey/.m2/repository/org/apache/maven/shared/maven-dependency-tree/2.2/maven-dependency-tree-2.2.jar
[ERROR] urls[3] = 
file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
[ERROR] urls[4] = 
file:/Users/busbey/.m2/repository/org/eclipse/aether/aether-util/0.9.0.M2/aether-util-0.9.0.M2.jar
[ERROR] urls[5] = 
file:/Users/busbey/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/1.4/maven-common-artifact-filters-1.4.jar
[ERROR] urls[6] = 
file:/Users/busbey/.m2/repository/com/ibm/icu/icu4j/56.1/icu4j-56.1.jar
[ERROR] urls[7] = 
file:/Users/busbey/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
[ERROR] urls[8] = 
file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
[ERROR] urls[9] = 
file:/Users/busbey/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
[ERROR] urls[10] = 
file:/Users/busbey/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
[ERROR] urls[11] = 
file:/Users/busbey/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.2.1/maven-reporting-api-2.2.1.jar
[ERROR] urls[12] = 
file:/Users/busbey/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.1/doxia-sink-api-1.1.jar
[ERROR] urls[13] = 
file:/Users/busbey/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.1/doxia-logging-api-1.1.jar
[ERROR] urls[14] = 
file:/Users/busbey/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
[ERROR] urls[15] = 
file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
[ERROR] urls[16] = 
file:/Users/busbey/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
[ERROR] urls[17] = 
file:/Users/busbey/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
[ERROR] urls[18] = 
file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar
[ERROR] urls[19] = 
file:/Users/busbey/.m2/repository/commons-lang/commons-lang/2.3/commons-lang-2.3.jar
[ERROR] urls[20] = 
file:/Users/busbey/.m2/repository/org/apache/maven/enforcer/enforcer-api/1.4/enforcer-api-1.4.jar
[ERROR] urls[21] = 
file:/Users/busbey/.m2/repository/org/apache/maven/enforcer/enforcer-rules/1.4/enforcer-rules-1.4.jar
[ERROR] urls[22] = 
file:/Users/busbey/.m2/repository/org/beanshell/bsh/2.0b4/bsh-2.0b4.jar
[ERROR] urls[23] = 
file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-6/plexus-i18n-1.0-beta-6.jar
[ERROR] urls[24] = 
file:/Users/busbey/.m2/repository/org/apache/maven/plugin-testing/maven-plugin-testing-harness/1.3/maven-plugin-testing-harness-1.3.jar
[ERROR] urls[25] = 
file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-archiver/2.2/plexus-archiver-2.2.jar
[ERROR] urls[26] = 
file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.jar
[ERROR] urls[27] = 
file:/Users/busbey/.m2/repository/junit/junit/4.11/junit-4.11.jar
[ERROR] urls[28] = 
file:/Users/busbey/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import  from realm 
ClassRealm[project>org.apache.hbase:hbase:3.0.0-SNAPSHOT, parent: 
ClassRealm[maven.api, parent: null]]]
[ERROR] 
[ERROR] -

{code}



--
This message was sent 

[jira] [Created] (HBASE-18866) clean up warnings about proto syntax

[Sean Busbey (JIRA)]

Sean Busbey created HBASE-18866:
---

 Summary: clean up warnings about proto syntax
 Key: HBASE-18866
 URL: https://issues.apache.org/jira/browse/HBASE-18866
 Project: HBase
  Issue Type: Bug
  Components: Protobufs
Affects Versions: 2.0.0-alpha-3, 3.0.0
Reporter: Sean Busbey
Assignee: Sean Busbey
Priority: Minor
 Fix For: 3.0.0, 2.0.0-alpha-4


build spits out a bunch of warnings like:

{code}
[INFO] 
[INFO] --- protobuf-maven-plugin:0.5.0:compile (compile-protoc) @ 
hbase-protocol-shaded ---
[INFO] Compiling 32 proto file(s) to 
/Users/busbey/tmp_projects/hbase/hbase-protocol-shaded/target/generated-sources/protobuf/java
[WARNING] PROTOC: [libprotobuf WARNING google/protobuf/compiler/parser.cc:546] 
No syntax specified for the proto file: AccessControl.proto. Please use 'syntax 
= "proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted to 
proto2 syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: HBase.proto. Please use 'syntax = "proto2";' or 
'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: Admin.proto. Please use 'syntax = "proto2";' or 
'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: ClusterStatus.proto. Please use 'syntax = 
"proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted to 
proto2 syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: ClusterId.proto. Please use 'syntax = "proto2";' 
or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 
syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: FS.proto. Please use 'syntax = "proto2";' or 
'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: WAL.proto. Please use 'syntax = "proto2";' or 
'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: Quota.proto. Please use 'syntax = "proto2";' or 
'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: Backup.proto. Please use 'syntax = "proto2";' or 
'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: Cell.proto. Please use 'syntax = "proto2";' or 
'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: Client.proto. Please use 'syntax = "proto2";' or 
'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: Filter.proto. Please use 'syntax = "proto2";' or 
'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: Comparator.proto. Please use 'syntax = "proto2";' 
or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 
syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: MapReduce.proto. Please use 'syntax = "proto2";' 
or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 
syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: Encryption.proto. Please use 'syntax = "proto2";' 
or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 
syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: ErrorHandling.proto. Please use 'syntax = 
"proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted to 
proto2 syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: HFile.proto. Please use 'syntax = "proto2";' or 
'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax 
specified for the proto file: LoadBalancer.proto. Please use 'syntax = 
"proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted 

Re: [DISCUSS] Increase stability on o.a.h.h.Tag?

[Vrushali C]

bq. Thanks Vrushali. We are currently in the throes of refactoring our
Coprocessor API. Let us use the Timeline Service Coprocessors as our guinea
pigs migrating off the old to the new, so you don't have to do it (smile).

Thanks Stack, all yours! I have been lurking on Appy's HBASE-17732 and am
trying to follow along.

Do let me know if/how I can help.

thanks
Vrushali


On Fri, Sep 22, 2017 at 12:50 PM, Stack  wrote:

> On Fri, Sep 22, 2017 at 12:27 PM, Vrushali C 
> wrote:
>
> > Thanks everyone.
> >
> > bq. Thanks for the context in this thread, Vrushali. The information
> you've
> > provided has been helpful.
> >
> > Sure, happy to chat further if anyone wants.
> >
> > Here are the two files which actually operate on Tags in YARN Timeline
> > service. We are using HBase 1.2.6 at present.
> >
> > https://github.com/apache/hadoop/blob/trunk/hadoop-yarn-
> > project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-
> > server-timelineservice-hbase/src/main/java/org/apache/
> hadoop/yarn/server/
> > timelineservice/storage/flow/FlowRunCoprocessor.java
> >
> > https://github.com/apache/hadoop/blob/trunk/hadoop-yarn-
> > project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-
> > server-timelineservice-hbase/src/main/java/org/apache/
> hadoop/yarn/server/
> > timelineservice/storage/flow/FlowScanner.java
> >
> > There are some utility functions in
> > https://github.com/apache/hadoop/blob/trunk/hadoop-yarn-
> > project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-
> > server-timelineservice-hbase/src/main/java/org/apache/
> hadoop/yarn/server/
> > timelineservice/storage/common/HBaseTimelineStorageUtils.java
> >
> > which are called from the FlowScanner and FlowRunCoprocessor classes.
> >
> >
> Thanks Vrushali. We are currently in the throes of refactoring our
> Coprocessor API. Let us use the Timeline Service Coprocessors as our guinea
> pigs migrating off the old to the new, so you don't have to do it (smile).
>
> S
>
>
>
> > thanks
> > Vrushali
> >
> >
> > On Fri, Sep 22, 2017 at 10:52 AM, Josh Elser  wrote:
> >
> > > Sounds like we have some consensus to make a switch to
> > > LimitedPrivate(COPROC)+Evolving on Tag (and CellUtil methods?) for
> 2.0?
> > I
> > > don't think we have to make API changes (to mitigate Sean's concerns of
> > > slowing 2.0). We can treat this as a "bigger" promise moving forward.
> > >
> > > I can open a JIRA issue to hash out the rest of the specifics if we're
> in
> > > agreement.
> > >
> > > Thanks for the context in this thread, Vrushali. The information you've
> > > provided has been helpful.
> > >
> > >
> > > On 9/22/17 1:09 PM, Andrew Purtell wrote:
> > >
> > >> In my opinion that's a valid use case we should support with
> appropriate
> > >> changes to interface annotations and, therefore, stability. I don't
> > >> believe
> > >> the interfaces have been changing much, so this shouldn't represent a
> > >> problem other than maybe we want to review what we have before
> promoting
> > >> them. The security coprocessors do the same: they use tags to add
> > special
> > >> metadata to cells, then apply additional logic/filtering while
> > overriding
> > >> some scanner behavior.
> > >>
> > >>
> > >> On Fri, Sep 22, 2017 at 9:54 AM, Vrushali C 
> > >> wrote:
> > >>
> > >> For what it's worth, Yarn Timeline Service v2 makes use of Tags only
> in
> > >>> the
> > >>> coprocessor code in the custom Scanner that is invoked during
> > >>> get/scan/compact and at the PrePut step.
> > >>>
> > >>> thanks
> > >>> Vrushali
> > >>>
> > >>>
> > >>> On Fri, Sep 22, 2017 at 9:20 AM, Andrew Purtell <
> > >>> andrew.purt...@gmail.com>
> > >>> wrote:
> > >>>
> > >>> I think not making the relevant APIs LP(Coprocessor) was an
> oversight.
> > In
> >  my opinion we should do that. I'm not sure about Public. We could do
> >  that
> >  too but somewhere we need to call out that coprocessors have access
> to
> >  tags, but not clients. (Tags are removed at RPC except for
> > replication.)
> > 
> > >>> LP
> > >>>
> >  doesn't imply what Public might.
> > 
> >  On Sep 22, 2017, at 9:11 AM, Andrew Purtell <
> andrew.purt...@gmail.com
> > >
> > >
> >  wrote:
> > 
> > >
> > > Tags are server side internal metadata. Some carry sensitive
> > >
> >  information
> > >>>
> >  like labels. I guess this could appear odd if not around for
> > discussion
> >  when they were introduced. So what documentation can be improved to
> > 
> > >>> lessen
> > >>>
> >  the surprise? Javadoc? Online book? A JIRA with suggestions welcome.
> > 
> > >
> > >
> > > On Sep 22, 2017, at 9:07 AM, Josh Elser  wrote:
> > >>
> > >> I can appreciate how we've gotten to this point, it just struck me
> > >>
> > > extremely odd that the contents of a Tag weren't expected to be
> >  accessed
> > 
> > >>> by
> > >>>
> >  users. 

Re: [DISCUSS] Increase stability on o.a.h.h.Tag?

[Stack]

On Fri, Sep 22, 2017 at 12:27 PM, Vrushali C 
wrote:

> Thanks everyone.
>
> bq. Thanks for the context in this thread, Vrushali. The information you've
> provided has been helpful.
>
> Sure, happy to chat further if anyone wants.
>
> Here are the two files which actually operate on Tags in YARN Timeline
> service. We are using HBase 1.2.6 at present.
>
> https://github.com/apache/hadoop/blob/trunk/hadoop-yarn-
> project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-
> server-timelineservice-hbase/src/main/java/org/apache/hadoop/yarn/server/
> timelineservice/storage/flow/FlowRunCoprocessor.java
>
> https://github.com/apache/hadoop/blob/trunk/hadoop-yarn-
> project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-
> server-timelineservice-hbase/src/main/java/org/apache/hadoop/yarn/server/
> timelineservice/storage/flow/FlowScanner.java
>
> There are some utility functions in
> https://github.com/apache/hadoop/blob/trunk/hadoop-yarn-
> project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-
> server-timelineservice-hbase/src/main/java/org/apache/hadoop/yarn/server/
> timelineservice/storage/common/HBaseTimelineStorageUtils.java
>
> which are called from the FlowScanner and FlowRunCoprocessor classes.
>
>
Thanks Vrushali. We are currently in the throes of refactoring our
Coprocessor API. Let us use the Timeline Service Coprocessors as our guinea
pigs migrating off the old to the new, so you don't have to do it (smile).

S



> thanks
> Vrushali
>
>
> On Fri, Sep 22, 2017 at 10:52 AM, Josh Elser  wrote:
>
> > Sounds like we have some consensus to make a switch to
> > LimitedPrivate(COPROC)+Evolving on Tag (and CellUtil methods?) for 2.0?
> I
> > don't think we have to make API changes (to mitigate Sean's concerns of
> > slowing 2.0). We can treat this as a "bigger" promise moving forward.
> >
> > I can open a JIRA issue to hash out the rest of the specifics if we're in
> > agreement.
> >
> > Thanks for the context in this thread, Vrushali. The information you've
> > provided has been helpful.
> >
> >
> > On 9/22/17 1:09 PM, Andrew Purtell wrote:
> >
> >> In my opinion that's a valid use case we should support with appropriate
> >> changes to interface annotations and, therefore, stability. I don't
> >> believe
> >> the interfaces have been changing much, so this shouldn't represent a
> >> problem other than maybe we want to review what we have before promoting
> >> them. The security coprocessors do the same: they use tags to add
> special
> >> metadata to cells, then apply additional logic/filtering while
> overriding
> >> some scanner behavior.
> >>
> >>
> >> On Fri, Sep 22, 2017 at 9:54 AM, Vrushali C 
> >> wrote:
> >>
> >> For what it's worth, Yarn Timeline Service v2 makes use of Tags only in
> >>> the
> >>> coprocessor code in the custom Scanner that is invoked during
> >>> get/scan/compact and at the PrePut step.
> >>>
> >>> thanks
> >>> Vrushali
> >>>
> >>>
> >>> On Fri, Sep 22, 2017 at 9:20 AM, Andrew Purtell <
> >>> andrew.purt...@gmail.com>
> >>> wrote:
> >>>
> >>> I think not making the relevant APIs LP(Coprocessor) was an oversight.
> In
>  my opinion we should do that. I'm not sure about Public. We could do
>  that
>  too but somewhere we need to call out that coprocessors have access to
>  tags, but not clients. (Tags are removed at RPC except for
> replication.)
> 
> >>> LP
> >>>
>  doesn't imply what Public might.
> 
>  On Sep 22, 2017, at 9:11 AM, Andrew Purtell  >
> >
>  wrote:
> 
> >
> > Tags are server side internal metadata. Some carry sensitive
> >
>  information
> >>>
>  like labels. I guess this could appear odd if not around for
> discussion
>  when they were introduced. So what documentation can be improved to
> 
> >>> lessen
> >>>
>  the surprise? Javadoc? Online book? A JIRA with suggestions welcome.
> 
> >
> >
> > On Sep 22, 2017, at 9:07 AM, Josh Elser  wrote:
> >>
> >> I can appreciate how we've gotten to this point, it just struck me
> >>
> > extremely odd that the contents of a Tag weren't expected to be
>  accessed
> 
> >>> by
> >>>
>  users. "Arbitrary metadata that rides along with a cell, you just
> can't
> 
> >>> see
> >>>
>  that metadata" ;)
> 
> >
> >> I totally understand not wanting to let another thing come into 2.0.
> >>
> > Like MikeD said, let's hope for a faster 3.0 and we can slate this
> for
> 
> >>> that
> >>>
>  time.
> 
> >
> >> Thanks for entertaining the discussion. We'll just deal with the
> >>
> > "downstream pain" for 2.0.
> 
> >
> >> On 9/22/17 1:32 AM, ramkrishna vasudevan wrote:
> >>> CellUtil  similar type of methods. Coming to Tags yes there are not
> >>>
> >> much
> 
> > cases where clients can directly set Tags. And I think we don't
> 

Re: [DISCUSS] Increase stability on o.a.h.h.Tag?

[Vrushali C]

Thanks everyone.

bq. Thanks for the context in this thread, Vrushali. The information you've
provided has been helpful.

Sure, happy to chat further if anyone wants.

Here are the two files which actually operate on Tags in YARN Timeline
service. We are using HBase 1.2.6 at present.

https://github.com/apache/hadoop/blob/trunk/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase/src/main/java/org/apache/hadoop/yarn/server/timelineservice/storage/flow/FlowRunCoprocessor.java

https://github.com/apache/hadoop/blob/trunk/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase/src/main/java/org/apache/hadoop/yarn/server/timelineservice/storage/flow/FlowScanner.java

There are some utility functions in
https://github.com/apache/hadoop/blob/trunk/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase/src/main/java/org/apache/hadoop/yarn/server/timelineservice/storage/common/HBaseTimelineStorageUtils.java

which are called from the FlowScanner and FlowRunCoprocessor classes.

thanks
Vrushali


On Fri, Sep 22, 2017 at 10:52 AM, Josh Elser  wrote:

> Sounds like we have some consensus to make a switch to
> LimitedPrivate(COPROC)+Evolving on Tag (and CellUtil methods?) for 2.0? I
> don't think we have to make API changes (to mitigate Sean's concerns of
> slowing 2.0). We can treat this as a "bigger" promise moving forward.
>
> I can open a JIRA issue to hash out the rest of the specifics if we're in
> agreement.
>
> Thanks for the context in this thread, Vrushali. The information you've
> provided has been helpful.
>
>
> On 9/22/17 1:09 PM, Andrew Purtell wrote:
>
>> In my opinion that's a valid use case we should support with appropriate
>> changes to interface annotations and, therefore, stability. I don't
>> believe
>> the interfaces have been changing much, so this shouldn't represent a
>> problem other than maybe we want to review what we have before promoting
>> them. The security coprocessors do the same: they use tags to add special
>> metadata to cells, then apply additional logic/filtering while overriding
>> some scanner behavior.
>>
>>
>> On Fri, Sep 22, 2017 at 9:54 AM, Vrushali C 
>> wrote:
>>
>> For what it's worth, Yarn Timeline Service v2 makes use of Tags only in
>>> the
>>> coprocessor code in the custom Scanner that is invoked during
>>> get/scan/compact and at the PrePut step.
>>>
>>> thanks
>>> Vrushali
>>>
>>>
>>> On Fri, Sep 22, 2017 at 9:20 AM, Andrew Purtell <
>>> andrew.purt...@gmail.com>
>>> wrote:
>>>
>>> I think not making the relevant APIs LP(Coprocessor) was an oversight. In
 my opinion we should do that. I'm not sure about Public. We could do
 that
 too but somewhere we need to call out that coprocessors have access to
 tags, but not clients. (Tags are removed at RPC except for replication.)

>>> LP
>>>
 doesn't imply what Public might.

 On Sep 22, 2017, at 9:11 AM, Andrew Purtell 
>
 wrote:

>
> Tags are server side internal metadata. Some carry sensitive
>
 information
>>>
 like labels. I guess this could appear odd if not around for discussion
 when they were introduced. So what documentation can be improved to

>>> lessen
>>>
 the surprise? Javadoc? Online book? A JIRA with suggestions welcome.

>
>
> On Sep 22, 2017, at 9:07 AM, Josh Elser  wrote:
>>
>> I can appreciate how we've gotten to this point, it just struck me
>>
> extremely odd that the contents of a Tag weren't expected to be
 accessed

>>> by
>>>
 users. "Arbitrary metadata that rides along with a cell, you just can't

>>> see
>>>
 that metadata" ;)

>
>> I totally understand not wanting to let another thing come into 2.0.
>>
> Like MikeD said, let's hope for a faster 3.0 and we can slate this for

>>> that
>>>
 time.

>
>> Thanks for entertaining the discussion. We'll just deal with the
>>
> "downstream pain" for 2.0.

>
>> On 9/22/17 1:32 AM, ramkrishna vasudevan wrote:
>>> CellUtil  similar type of methods. Coming to Tags yes there are not
>>>
>> much

> cases where clients can directly set Tags. And I think we don't
>>>
>> expose
>>>
 any

> APIs which allow you to use mutations with Tags. So probably moving
>>>
>> to
>>>
 LimitedPrivate is better and mark with Evolving if there are some
>>>
>> users
>>>
 depending on the internals of Tags and its impl. But this will be a
>>>
>> One of

> case.
>>> And also since Tags are internal ideally the CellUtil#getTAgs()
>>>
>> should
>>>
 have

> been in another Util method that is exposed with LimitedPrivate and
>>>
>> also

> Tags if tags should be made 

Re: [DISCUSS] Increase stability on o.a.h.h.Tag?

[Andrew Purtell]

Tags are / were intended as special extra bits of metadata which may be
associated with a cell, therefore stored adjacent to the cell's serialized
representation, for use within the server process by coprocessors. They are
not meant to be user visible. The default RPC codec strips them out. The
replication RPC codec makes an exception so all cell state including tags
are replicated. The initial users for tags were the AccessController and
VisibiltyController coprocessors.


On Fri, Sep 22, 2017 at 10:46 AM, Josh Elser  wrote:

> Maybe my expectations are just invalid to start :)
>
> I'm thinking about the cell-level visibility feature specifically. I'm
> happy to back away from this point as I'm getting the impression that I'm
> trying to call an apple an orange.
>
> Let me take an action to read what currently does exist and come back
> later. I also need to look more closely at how YARN is using the Tags now
> to understand if they way they're using the feature is inappropriate out of
> the gates.
>
>
> On 9/22/17 12:11 PM, Andrew Purtell wrote:
>
>> Tags are server side internal metadata. Some carry sensitive information
>> like labels. I guess this could appear odd if not around for discussion
>> when they were introduced. So what documentation can be improved to lessen
>> the surprise? Javadoc? Online book? A JIRA with suggestions welcome.
>>
>>
>> On Sep 22, 2017, at 9:07 AM, Josh Elser  wrote:
>>>
>>> I can appreciate how we've gotten to this point, it just struck me
>>> extremely odd that the contents of a Tag weren't expected to be accessed by
>>> users. "Arbitrary metadata that rides along with a cell, you just can't see
>>> that metadata" ;)
>>>
>>> I totally understand not wanting to let another thing come into 2.0.
>>> Like MikeD said, let's hope for a faster 3.0 and we can slate this for that
>>> time.
>>>
>>> Thanks for entertaining the discussion. We'll just deal with the
>>> "downstream pain" for 2.0.
>>>
>>> On 9/22/17 1:32 AM, ramkrishna vasudevan wrote:
 CellUtil  similar type of methods. Coming to Tags yes there are not much
 cases where clients can directly set Tags. And I think we don't expose
 any
 APIs which allow you to use mutations with Tags. So probably moving to
 LimitedPrivate is better and mark with Evolving if there are some users
 depending on the internals of Tags and its impl. But this will be a One
 of
 case.
 And also since Tags are internal ideally the CellUtil#getTAgs() should
 have
 been in another Util method that is exposed with LimitedPrivate and also
 Tags if tags should be made LimitedPRivate. So this may help in not
 having
 a PRivate interface like Tag in a public CellUtil class.
 3.0 is fine but need some clean up in 2.0? Indicating what could happen
 going forward from 2.0?
 Regards
 Ram

> On Fri, Sep 22, 2017 at 2:59 AM, Sean Busbey 
> wrote:
> Yeah. I mean, I think we should improve  the situation. Just think
> it's too much to bite off at this stage of 2.0, we can aim for 3.0 and
> start working in some tooling to help us.
>
> On Thu, Sep 21, 2017 at 3:35 PM, Josh Elser  wrote:
>> That really makes me groan (we have downstream users depending on code
>>
> we've
>
>> explicitly said "don't use"), but if that's what it is given the
>> current
>> state, so be it. My complaining won't fix it.
>>
>> Thanks.
>>
>>
>> On 9/21/17 4:25 PM, Sean Busbey wrote:
>>>
>>> We have lots of examples of including non-Public stuff in Public
>>> APIs.
>>> we have docs that advise folks to be wary on relying on them beyond
>>> opaque symbols.
>>>
>>> ref: http://hbase.apache.org/book.html#hbase.client.api.surface
>>>
>>> On Thu, Sep 21, 2017 at 3:21 PM, Josh Elser 
 wrote:

 I was going to suggest LimitedPrivate in my original, but this
 doesn't
 make
 sense as we're exposing Public API via CellUtil.

 It seems odd to me that we wouldn't treat the cell tags as a
 supported
 API
 call. However, I'm happy to remain "confused" if the rest of folks

>>> don't
>
>> consider tags to be intended for users :)


 On 9/21/17 3:15 PM, Ted Yu wrote:
>
>
> Can we mark Tag LimitedPrivate ?
>
> We know how ATS uses Tags so it should be straight forward to keep
>
 their
>
>> usage intact.
>
> On Thu, Sep 21, 2017 at 12:03 PM, Josh Elser 
>
 wrote:
>
>>
> Hiya,
>>
>> (Background, I'm starting what is likely to be an onerous task of
>> looking
>> through downstream components and seeing what is broken with the
>>

Re: Please congratulate our new PMC Chair Misty Stanley-Jones

[Esteban Gutierrez]

Thats awesome! Congratulations, Misty!



--
Cloudera, Inc.


On Fri, Sep 22, 2017 at 11:27 AM, Alexander Leblang <
alex.lebl...@cloudera.com> wrote:

> Congrats Misty! Well done!
> On Fri, Sep 22, 2017 at 11:25 AM Wei-Chiu Chuang 
> wrote:
>
> > Congrats! Misty!!
> >
> > On Fri, Sep 22, 2017 at 7:50 AM, Jimmy Xiang  wrote:
> >
> > > Congrats! Misty!!
> > >
> > > On Fri, Sep 22, 2017 at 7:16 AM, Pankaj kr 
> wrote:
> > >
> > > > Congratulations Misty..!! :)
> > > >
> > > >
> > > > -Pankaj-
> > > >
> > > >
> > > > -Original Message-
> > > > From: Andrew Purtell [mailto:apurt...@apache.org]
> > > > Sent: Friday, September 22, 2017 3:08 AM
> > > > To: dev@hbase.apache.org; u...@hbase.apache.org
> > > > Subject: Please congratulate our new PMC Chair Misty Stanley-Jones
> > > >
> > > > At today's meeting of the Board, Special Resolution B changing the
> > HBase
> > > > project Chair to Misty Stanley-Jones was passed unanimously.
> > > >
> > > > Please join me in congratulating Misty on her new role!
> > > >
> > > > ​(If you need any help or advice please don't hesitate to ping me,
> > Misty,
> > > > but I suspect you'll do just fine and won't need it.)​
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew
> > > >
> > >
> >
> >
> >
> > --
> > A very happy Hadoop contributor
> >
>

[jira] [Resolved] (HBASE-18861) [C++] Use boost::optional instead of std::experimental::optional

[Enis Soztutar (JIRA)]

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

Enis Soztutar resolved HBASE-18861.
---
   Resolution: Fixed
Fix Version/s: HBASE-14850

> [C++] Use boost::optional instead of std::experimental::optional
> 
>
> Key: HBASE-18861
> URL: https://issues.apache.org/jira/browse/HBASE-18861
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: HBASE-14850
>
> Attachments: hbase-18861_v1.patch
>
>
> Our Marc Parisi indicates that using std::experimental is not prefered in 
> production code, and causes compilation problems especially for compilers 
> which do not have C++17 support. 
> Our usage of {{std::experimental::optional}} is very small and can be easily 
> replaced with {{boost::optional}}. We depend on boost anyways for other 
> reasons. 



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

Re: error installing Cyrus

[Ted Yu]

Andrzej:
There is
http://cyrusimap.web.cmu.edu/old/docs/cyrus-imapd/2.2.13p1/mailing-list.php

Please use appropriate mailing list for each specific question.

On Fri, Sep 22, 2017 at 11:02 AM, Andrzej  wrote:

> W dniu 22.09.2017 o 19:10, Ted Yu pisze:
>
>> Please refer to hbase-native-client/docker-files/Dockerfile for necessary
>> dependencies.
>>
>> The binaries built within docker should not be directly linked outside
>> docker, unless OS outside docker is the same as within.
>>
>
> I try:
> based on hbase-native/HBASE-14850/hbase-native-client/docker-files/Do
> ckerfile:
>
> wget ftp://ftp.cyrusimap.org/cyrus-sasl/cyrus-sasl-2.1.26.tar.gz
> tar zxf cyrus-sasl-2.1.26.tar.gz
> cd cyrus-sasl-2.1.26
> ./configure
> make
> sudo make install
>
> but are make errors:
> digestmd5.c:859:5: error: unknown type name 'des_key_schedule'
>  des_key_schedule keysched;  /* key schedule for des initialization */
>  ^
> digestmd5.c:860:5: error: unknown type name 'des_cblock'
>  des_cblock ivec;/* initial vector for encoding */
>  ^
> digestmd5.c:861:5: error: unknown type name 'des_key_schedule'
>  des_key_schedule keysched2; /* key schedule for 3des initialization */
>  ^
> digestmd5.c:902:5: error: 'DES_DECRYPT' undeclared (first use in this
> function)
>  DES_DECRYPT);
>
> =
> I have something not installed? But I don't get #include errors but DES
> idents errors.
>

Re: libsasl2.so.3 (branch HBASE-14850)

[Andrzej]

W dniu 22.09.2017 o 19:10, Ted Yu pisze:

Please refer to hbase-native-client/docker-files/Dockerfile for necessary
dependencies.

The binaries built within docker should not be directly linked outside
docker, unless OS outside docker is the same as within.


I try:
based on 
hbase-native/HBASE-14850/hbase-native-client/docker-files/Dockerfile:


wget ftp://ftp.cyrusimap.org/cyrus-sasl/cyrus-sasl-2.1.26.tar.gz
tar zxf cyrus-sasl-2.1.26.tar.gz
cd cyrus-sasl-2.1.26
./configure
make
sudo make install

but are make errors:
digestmd5.c:859:5: error: unknown type name 'des_key_schedule'
 des_key_schedule keysched;  /* key schedule for des initialization */
 ^
digestmd5.c:860:5: error: unknown type name 'des_cblock'
 des_cblock ivec;/* initial vector for encoding */
 ^
digestmd5.c:861:5: error: unknown type name 'des_key_schedule'
 des_key_schedule keysched2; /* key schedule for 3des initialization */
 ^
digestmd5.c:902:5: error: 'DES_DECRYPT' undeclared (first use in this 
function)

 DES_DECRYPT);

=
I have something not installed? But I don't get #include errors but DES 
idents errors.

Re: [DISCUSS] Increase stability on o.a.h.h.Tag?

[Josh Elser]

Sounds like we have some consensus to make a switch to 
LimitedPrivate(COPROC)+Evolving on Tag (and CellUtil methods?) for 2.0? 
I don't think we have to make API changes (to mitigate Sean's concerns 
of slowing 2.0). We can treat this as a "bigger" promise moving forward.


I can open a JIRA issue to hash out the rest of the specifics if we're 
in agreement.


Thanks for the context in this thread, Vrushali. The information you've 
provided has been helpful.


On 9/22/17 1:09 PM, Andrew Purtell wrote:

In my opinion that's a valid use case we should support with appropriate
changes to interface annotations and, therefore, stability. I don't believe
the interfaces have been changing much, so this shouldn't represent a
problem other than maybe we want to review what we have before promoting
them. The security coprocessors do the same: they use tags to add special
metadata to cells, then apply additional logic/filtering while overriding
some scanner behavior.


On Fri, Sep 22, 2017 at 9:54 AM, Vrushali C  wrote:


For what it's worth, Yarn Timeline Service v2 makes use of Tags only in the
coprocessor code in the custom Scanner that is invoked during
get/scan/compact and at the PrePut step.

thanks
Vrushali


On Fri, Sep 22, 2017 at 9:20 AM, Andrew Purtell 
wrote:


I think not making the relevant APIs LP(Coprocessor) was an oversight. In
my opinion we should do that. I'm not sure about Public. We could do that
too but somewhere we need to call out that coprocessors have access to
tags, but not clients. (Tags are removed at RPC except for replication.)

LP

doesn't imply what Public might.


On Sep 22, 2017, at 9:11 AM, Andrew Purtell 

wrote:


Tags are server side internal metadata. Some carry sensitive

information

like labels. I guess this could appear odd if not around for discussion
when they were introduced. So what documentation can be improved to

lessen

the surprise? Javadoc? Online book? A JIRA with suggestions welcome.




On Sep 22, 2017, at 9:07 AM, Josh Elser  wrote:

I can appreciate how we've gotten to this point, it just struck me

extremely odd that the contents of a Tag weren't expected to be accessed

by

users. "Arbitrary metadata that rides along with a cell, you just can't

see

that metadata" ;)


I totally understand not wanting to let another thing come into 2.0.

Like MikeD said, let's hope for a faster 3.0 and we can slate this for

that

time.


Thanks for entertaining the discussion. We'll just deal with the

"downstream pain" for 2.0.



On 9/22/17 1:32 AM, ramkrishna vasudevan wrote:
CellUtil  similar type of methods. Coming to Tags yes there are not

much

cases where clients can directly set Tags. And I think we don't

expose

any

APIs which allow you to use mutations with Tags. So probably moving

to

LimitedPrivate is better and mark with Evolving if there are some

users

depending on the internals of Tags and its impl. But this will be a

One of

case.
And also since Tags are internal ideally the CellUtil#getTAgs()

should

have

been in another Util method that is exposed with LimitedPrivate and

also

Tags if tags should be made LimitedPRivate. So this may help in not

having

a PRivate interface like Tag in a public CellUtil class.
3.0 is fine but need some clean up in 2.0? Indicating what could

happen

going forward from 2.0?
Regards
Ram

On Fri, Sep 22, 2017 at 2:59 AM, Sean Busbey 

wrote:

Yeah. I mean, I think we should improve  the situation. Just think
it's too much to bite off at this stage of 2.0, we can aim for 3.0

and

start working in some tooling to help us.


On Thu, Sep 21, 2017 at 3:35 PM, Josh Elser 

wrote:

That really makes me groan (we have downstream users depending on

code

we've

explicitly said "don't use"), but if that's what it is given the

current

state, so be it. My complaining won't fix it.

Thanks.



On 9/21/17 4:25 PM, Sean Busbey wrote:

We have lots of examples of including non-Public stuff in Public

APIs.

we have docs that advise folks to be wary on relying on them

beyond

opaque symbols.

ref: http://hbase.apache.org/book.html#hbase.client.api.surface


On Thu, Sep 21, 2017 at 3:21 PM, Josh Elser 

wrote:


I was going to suggest LimitedPrivate in my original, but this

doesn't

make
sense as we're exposing Public API via CellUtil.

It seems odd to me that we wouldn't treat the cell tags as a

supported

API
call. However, I'm happy to remain "confused" if the rest of

folks

don't

consider tags to be intended for users :)



On 9/21/17 3:15 PM, Ted Yu wrote:


Can we mark Tag LimitedPrivate ?

We know how ATS uses Tags so it should be straight forward to

keep

their

usage intact.

On Thu, Sep 21, 2017 at 12:03 PM, Josh Elser 

Re: [DISCUSS] Increase stability on o.a.h.h.Tag?

[Josh Elser]

Maybe my expectations are just invalid to start :)

I'm thinking about the cell-level visibility feature specifically. I'm 
happy to back away from this point as I'm getting the impression that 
I'm trying to call an apple an orange.


Let me take an action to read what currently does exist and come back 
later. I also need to look more closely at how YARN is using the Tags 
now to understand if they way they're using the feature is inappropriate 
out of the gates.


On 9/22/17 12:11 PM, Andrew Purtell wrote:

Tags are server side internal metadata. Some carry sensitive information like 
labels. I guess this could appear odd if not around for discussion when they 
were introduced. So what documentation can be improved to lessen the surprise? 
Javadoc? Online book? A JIRA with suggestions welcome.



On Sep 22, 2017, at 9:07 AM, Josh Elser  wrote:

I can appreciate how we've gotten to this point, it just struck me extremely odd that the 
contents of a Tag weren't expected to be accessed by users. "Arbitrary metadata that 
rides along with a cell, you just can't see that metadata" ;)

I totally understand not wanting to let another thing come into 2.0. Like MikeD 
said, let's hope for a faster 3.0 and we can slate this for that time.

Thanks for entertaining the discussion. We'll just deal with the "downstream 
pain" for 2.0.


On 9/22/17 1:32 AM, ramkrishna vasudevan wrote:
CellUtil  similar type of methods. Coming to Tags yes there are not much
cases where clients can directly set Tags. And I think we don't expose any
APIs which allow you to use mutations with Tags. So probably moving to
LimitedPrivate is better and mark with Evolving if there are some users
depending on the internals of Tags and its impl. But this will be a One of
case.
And also since Tags are internal ideally the CellUtil#getTAgs() should have
been in another Util method that is exposed with LimitedPrivate and also
Tags if tags should be made LimitedPRivate. So this may help in not having
a PRivate interface like Tag in a public CellUtil class.
3.0 is fine but need some clean up in 2.0? Indicating what could happen
going forward from 2.0?
Regards
Ram

On Fri, Sep 22, 2017 at 2:59 AM, Sean Busbey  wrote:
Yeah. I mean, I think we should improve  the situation. Just think
it's too much to bite off at this stage of 2.0, we can aim for 3.0 and
start working in some tooling to help us.


On Thu, Sep 21, 2017 at 3:35 PM, Josh Elser  wrote:
That really makes me groan (we have downstream users depending on code

we've

explicitly said "don't use"), but if that's what it is given the current
state, so be it. My complaining won't fix it.

Thanks.



On 9/21/17 4:25 PM, Sean Busbey wrote:

We have lots of examples of including non-Public stuff in Public APIs.
we have docs that advise folks to be wary on relying on them beyond
opaque symbols.

ref: http://hbase.apache.org/book.html#hbase.client.api.surface


On Thu, Sep 21, 2017 at 3:21 PM, Josh Elser  wrote:

I was going to suggest LimitedPrivate in my original, but this doesn't
make
sense as we're exposing Public API via CellUtil.

It seems odd to me that we wouldn't treat the cell tags as a supported
API
call. However, I'm happy to remain "confused" if the rest of folks

don't

consider tags to be intended for users :)



On 9/21/17 3:15 PM, Ted Yu wrote:


Can we mark Tag LimitedPrivate ?

We know how ATS uses Tags so it should be straight forward to keep

their

usage intact.

On Thu, Sep 21, 2017 at 12:03 PM, Josh Elser 

wrote:



Hiya,

(Background, I'm starting what is likely to be an onerous task of
looking
through downstream components and seeing what is broken with the

latest

hbase-2.0.0*)

Looking at YARN's use of HBase for the Application TimelineServer, I
see
that they're relying on the Tag interface.

Presently, Tag is marked as Private, yet we expose it via the Public
CellUtil.

My gut reaction is that we should bump Tag up Public since the intent
is
for downstream users to, ya know, use those Tags. Any objections?

If we don't want to expose Tag, we should make a pass over the Public
methods and mark them as Private (so not as to provide a Public

method

with
Private objects). CellUtil#getTag(Cell, byte) would be one such
example.

- Josh

[jira] [Created] (HBASE-18865) Ensure system tables can have their WALs split prior to user tables

[Sean Busbey (JIRA)]

Sean Busbey created HBASE-18865:
---

 Summary: Ensure system tables can have their WALs split prior to 
user tables
 Key: HBASE-18865
 URL: https://issues.apache.org/jira/browse/HBASE-18865
 Project: HBase
  Issue Type: New Feature
  Components: wal
Affects Versions: 2.0.0
Reporter: Sean Busbey
Priority: Critical
 Fix For: 2.0.0


>From a comment on HBASE-14190 and repeated on HBASE-18109 from [~yangzhe1991]:

{quote}
If I am not wrong, for system tables expect meta we still share logs with user 
regions, so even if we have some logic to assign system tables first, we still 
need wait log splitting done and we can not guarantee logs of system tables are 
split first. So there may be a blocking task that we should make multi-log 
feature having priority and write entries of system table in the highest 
priority logs. Thanks.
{quote}

This is an umbrella for working out our long term plan around how we handle WAL 
prioritization and recovery.



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

Re: libsasl2.so.3 (branch HBASE-14850)

[Ted Yu]

Please refer to hbase-native-client/docker-files/Dockerfile for necessary
dependencies.

The binaries built within docker should not be directly linked outside
docker, unless OS outside docker is the same as within.

On Fri, Sep 22, 2017 at 10:08 AM, Andrzej  wrote:

> W dniu 22.09.2017 o 18:57, Ted Yu pisze:
> > So libsasl2.so.3 is in your docker VM.
> > Can you give the full error w.r.t. libsasl2.so.3 not being opened (I
> assume
> > you got the error within docker) ?
>
> No, build is ok within docker, but I can't use it outside docker
>
> Previous I have problems with forcing Buck to rebuild, but I have restored
> VirtualBox snapshot of Linux.
>

Re: [DISCUSS] Increase stability on o.a.h.h.Tag?

[Andrew Purtell]

In my opinion that's a valid use case we should support with appropriate
changes to interface annotations and, therefore, stability. I don't believe
the interfaces have been changing much, so this shouldn't represent a
problem other than maybe we want to review what we have before promoting
them. The security coprocessors do the same: they use tags to add special
metadata to cells, then apply additional logic/filtering while overriding
some scanner behavior.


On Fri, Sep 22, 2017 at 9:54 AM, Vrushali C  wrote:

> For what it's worth, Yarn Timeline Service v2 makes use of Tags only in the
> coprocessor code in the custom Scanner that is invoked during
> get/scan/compact and at the PrePut step.
>
> thanks
> Vrushali
>
>
> On Fri, Sep 22, 2017 at 9:20 AM, Andrew Purtell 
> wrote:
>
> > I think not making the relevant APIs LP(Coprocessor) was an oversight. In
> > my opinion we should do that. I'm not sure about Public. We could do that
> > too but somewhere we need to call out that coprocessors have access to
> > tags, but not clients. (Tags are removed at RPC except for replication.)
> LP
> > doesn't imply what Public might.
> >
> > > On Sep 22, 2017, at 9:11 AM, Andrew Purtell 
> > wrote:
> > >
> > > Tags are server side internal metadata. Some carry sensitive
> information
> > like labels. I guess this could appear odd if not around for discussion
> > when they were introduced. So what documentation can be improved to
> lessen
> > the surprise? Javadoc? Online book? A JIRA with suggestions welcome.
> > >
> > >
> > >> On Sep 22, 2017, at 9:07 AM, Josh Elser  wrote:
> > >>
> > >> I can appreciate how we've gotten to this point, it just struck me
> > extremely odd that the contents of a Tag weren't expected to be accessed
> by
> > users. "Arbitrary metadata that rides along with a cell, you just can't
> see
> > that metadata" ;)
> > >>
> > >> I totally understand not wanting to let another thing come into 2.0.
> > Like MikeD said, let's hope for a faster 3.0 and we can slate this for
> that
> > time.
> > >>
> > >> Thanks for entertaining the discussion. We'll just deal with the
> > "downstream pain" for 2.0.
> > >>
> > >>> On 9/22/17 1:32 AM, ramkrishna vasudevan wrote:
> > >>> CellUtil  similar type of methods. Coming to Tags yes there are not
> > much
> > >>> cases where clients can directly set Tags. And I think we don't
> expose
> > any
> > >>> APIs which allow you to use mutations with Tags. So probably moving
> to
> > >>> LimitedPrivate is better and mark with Evolving if there are some
> users
> > >>> depending on the internals of Tags and its impl. But this will be a
> > One of
> > >>> case.
> > >>> And also since Tags are internal ideally the CellUtil#getTAgs()
> should
> > have
> > >>> been in another Util method that is exposed with LimitedPrivate and
> > also
> > >>> Tags if tags should be made LimitedPRivate. So this may help in not
> > having
> > >>> a PRivate interface like Tag in a public CellUtil class.
> > >>> 3.0 is fine but need some clean up in 2.0? Indicating what could
> happen
> > >>> going forward from 2.0?
> > >>> Regards
> > >>> Ram
> >  On Fri, Sep 22, 2017 at 2:59 AM, Sean Busbey 
> > wrote:
> >  Yeah. I mean, I think we should improve  the situation. Just think
> >  it's too much to bite off at this stage of 2.0, we can aim for 3.0
> and
> >  start working in some tooling to help us.
> > 
> > > On Thu, Sep 21, 2017 at 3:35 PM, Josh Elser 
> > wrote:
> > > That really makes me groan (we have downstream users depending on
> > code
> >  we've
> > > explicitly said "don't use"), but if that's what it is given the
> > current
> > > state, so be it. My complaining won't fix it.
> > >
> > > Thanks.
> > >
> > >
> > >> On 9/21/17 4:25 PM, Sean Busbey wrote:
> > >>
> > >> We have lots of examples of including non-Public stuff in Public
> > APIs.
> > >> we have docs that advise folks to be wary on relying on them
> beyond
> > >> opaque symbols.
> > >>
> > >> ref: http://hbase.apache.org/book.html#hbase.client.api.surface
> > >>
> > >>> On Thu, Sep 21, 2017 at 3:21 PM, Josh Elser 
> > wrote:
> > >>>
> > >>> I was going to suggest LimitedPrivate in my original, but this
> > doesn't
> > >>> make
> > >>> sense as we're exposing Public API via CellUtil.
> > >>>
> > >>> It seems odd to me that we wouldn't treat the cell tags as a
> > supported
> > >>> API
> > >>> call. However, I'm happy to remain "confused" if the rest of
> folks
> >  don't
> > >>> consider tags to be intended for users :)
> > >>>
> > >>>
> >  On 9/21/17 3:15 PM, Ted Yu wrote:
> > 
> > 
> >  Can we mark Tag LimitedPrivate ?
> > 
> >  We know how ATS uses Tags so it should be straight forward 

Re: libsasl2.so.3 (branch HBASE-14850)

[Andrzej]

W dniu 22.09.2017 o 18:57, Ted Yu pisze:
> So libsasl2.so.3 is in your docker VM.
> Can you give the full error w.r.t. libsasl2.so.3 not being opened (I 
assume

> you got the error within docker) ?

No, build is ok within docker, but I can't use it outside docker

Previous I have problems with forcing Buck to rebuild, but I have 
restored VirtualBox snapshot of Linux.

Re: [DISCUSS] Increase stability on o.a.h.h.Tag?

[Ted Yu]

I am in favor of adding LimitedPrivate(Coprocessor) to Tag related API.

On Fri, Sep 22, 2017 at 9:54 AM, Vrushali C  wrote:

> For what it's worth, Yarn Timeline Service v2 makes use of Tags only in the
> coprocessor code in the custom Scanner that is invoked during
> get/scan/compact and at the PrePut step.
>
> thanks
> Vrushali
>
>
> On Fri, Sep 22, 2017 at 9:20 AM, Andrew Purtell 
> wrote:
>
> > I think not making the relevant APIs LP(Coprocessor) was an oversight. In
> > my opinion we should do that. I'm not sure about Public. We could do that
> > too but somewhere we need to call out that coprocessors have access to
> > tags, but not clients. (Tags are removed at RPC except for replication.)
> LP
> > doesn't imply what Public might.
> >
> > > On Sep 22, 2017, at 9:11 AM, Andrew Purtell 
> > wrote:
> > >
> > > Tags are server side internal metadata. Some carry sensitive
> information
> > like labels. I guess this could appear odd if not around for discussion
> > when they were introduced. So what documentation can be improved to
> lessen
> > the surprise? Javadoc? Online book? A JIRA with suggestions welcome.
> > >
> > >
> > >> On Sep 22, 2017, at 9:07 AM, Josh Elser  wrote:
> > >>
> > >> I can appreciate how we've gotten to this point, it just struck me
> > extremely odd that the contents of a Tag weren't expected to be accessed
> by
> > users. "Arbitrary metadata that rides along with a cell, you just can't
> see
> > that metadata" ;)
> > >>
> > >> I totally understand not wanting to let another thing come into 2.0.
> > Like MikeD said, let's hope for a faster 3.0 and we can slate this for
> that
> > time.
> > >>
> > >> Thanks for entertaining the discussion. We'll just deal with the
> > "downstream pain" for 2.0.
> > >>
> > >>> On 9/22/17 1:32 AM, ramkrishna vasudevan wrote:
> > >>> CellUtil  similar type of methods. Coming to Tags yes there are not
> > much
> > >>> cases where clients can directly set Tags. And I think we don't
> expose
> > any
> > >>> APIs which allow you to use mutations with Tags. So probably moving
> to
> > >>> LimitedPrivate is better and mark with Evolving if there are some
> users
> > >>> depending on the internals of Tags and its impl. But this will be a
> > One of
> > >>> case.
> > >>> And also since Tags are internal ideally the CellUtil#getTAgs()
> should
> > have
> > >>> been in another Util method that is exposed with LimitedPrivate and
> > also
> > >>> Tags if tags should be made LimitedPRivate. So this may help in not
> > having
> > >>> a PRivate interface like Tag in a public CellUtil class.
> > >>> 3.0 is fine but need some clean up in 2.0? Indicating what could
> happen
> > >>> going forward from 2.0?
> > >>> Regards
> > >>> Ram
> >  On Fri, Sep 22, 2017 at 2:59 AM, Sean Busbey 
> > wrote:
> >  Yeah. I mean, I think we should improve  the situation. Just think
> >  it's too much to bite off at this stage of 2.0, we can aim for 3.0
> and
> >  start working in some tooling to help us.
> > 
> > > On Thu, Sep 21, 2017 at 3:35 PM, Josh Elser 
> > wrote:
> > > That really makes me groan (we have downstream users depending on
> > code
> >  we've
> > > explicitly said "don't use"), but if that's what it is given the
> > current
> > > state, so be it. My complaining won't fix it.
> > >
> > > Thanks.
> > >
> > >
> > >> On 9/21/17 4:25 PM, Sean Busbey wrote:
> > >>
> > >> We have lots of examples of including non-Public stuff in Public
> > APIs.
> > >> we have docs that advise folks to be wary on relying on them
> beyond
> > >> opaque symbols.
> > >>
> > >> ref: http://hbase.apache.org/book.html#hbase.client.api.surface
> > >>
> > >>> On Thu, Sep 21, 2017 at 3:21 PM, Josh Elser 
> > wrote:
> > >>>
> > >>> I was going to suggest LimitedPrivate in my original, but this
> > doesn't
> > >>> make
> > >>> sense as we're exposing Public API via CellUtil.
> > >>>
> > >>> It seems odd to me that we wouldn't treat the cell tags as a
> > supported
> > >>> API
> > >>> call. However, I'm happy to remain "confused" if the rest of
> folks
> >  don't
> > >>> consider tags to be intended for users :)
> > >>>
> > >>>
> >  On 9/21/17 3:15 PM, Ted Yu wrote:
> > 
> > 
> >  Can we mark Tag LimitedPrivate ?
> > 
> >  We know how ATS uses Tags so it should be straight forward to
> keep
> >  their
> >  usage intact.
> > 
> >  On Thu, Sep 21, 2017 at 12:03 PM, Josh Elser  >
> >  wrote:
> > 
> > > Hiya,
> > >
> > > (Background, I'm starting what is likely to be an onerous task
> of
> > > looking
> > > through downstream components and seeing what is broken with
> the

Re: libsasl2.so.3 (branch HBASE-14850)

[Ted Yu]

So libsasl2.so.3 is in your docker VM.

Can you give the full error w.r.t. libsasl2.so.3 not being opened (I assume
you got the error within docker) ?

On Fri, Sep 22, 2017 at 9:53 AM, Andrzej  wrote:

> W dniu 22.09.2017 o 18:19, Ted Yu pisze:
>
>> On my docker VM, I found the following:
>>
>> /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25
>> /usr/lib/x86_64-linux-gnu/libsasl2.so.2
>> /usr/local/lib/libsasl2.so.3.0.0
>> /usr/local/lib/libsasl2.so.3
>>
>
> In my docker:
> root@securecluster:/usr/src/hbase/hbase-native-client# whereis  libsasl2
> libsasl2: /usr/local/lib/libsasl2.so /usr/local/lib/libsasl2.la
> root@securecluster:/usr/src/hbase/hbase-native-client# ls
> /usr/local/lib/libsasl*
> /usr/local/lib/libsasl2.la  /usr/local/lib/libsasl2.so.3
> /usr/local/lib/libsasl2.so  /usr/local/lib/libsasl2.so.3.0.0
> root@securecluster:/usr/src/hbase/hbase-native-client#
>
>
> Take a look at the first RUN command in:
>>
>> hbase-native-client/docker-files/Dockerfile
>>
>
> FROM pjameson/buck-folly-watchman:20160511
>
> ARG CC=/usr/bin/gcc-5
> ARG CXX=/usr/bin/g++-5
> ARG CFLAGS="-D_GLIBCXX_USE_CXX11_ABI=0 -fPIC -g -fno-omit-frame-pointer
> -O2 -pthread"
> ARG CXXFLAGS="-D_GLIBCXX_USE_CXX11_ABI=0 -fPIC -g -fno-omit-frame-pointer
> -O2 -pthread"
>
> ENV JAVA_HOME="/usr/lib/jvm/java-8-openjdk-amd64/"
>
> RUN wget ftp://ftp.cyrusimap.org/cyrus-sasl/cyrus-sasl-2.1.26.tar.gz ; \
> tar zxf cyrus-sasl-2.1.26.tar.gz ; \
> cd cyrus-sasl-2.1.26 ; \
> ./configure ; \
> make ; \
> make install ;\
> cp /usr/local/lib/sasl2/* /usr/lib/sasl2/
>
>
> Similar to this RUN I must do outside docker?
>

Re: [DISCUSS] Increase stability on o.a.h.h.Tag?

[Vrushali C]

For what it's worth, Yarn Timeline Service v2 makes use of Tags only in the
coprocessor code in the custom Scanner that is invoked during
get/scan/compact and at the PrePut step.

thanks
Vrushali


On Fri, Sep 22, 2017 at 9:20 AM, Andrew Purtell 
wrote:

> I think not making the relevant APIs LP(Coprocessor) was an oversight. In
> my opinion we should do that. I'm not sure about Public. We could do that
> too but somewhere we need to call out that coprocessors have access to
> tags, but not clients. (Tags are removed at RPC except for replication.) LP
> doesn't imply what Public might.
>
> > On Sep 22, 2017, at 9:11 AM, Andrew Purtell 
> wrote:
> >
> > Tags are server side internal metadata. Some carry sensitive information
> like labels. I guess this could appear odd if not around for discussion
> when they were introduced. So what documentation can be improved to lessen
> the surprise? Javadoc? Online book? A JIRA with suggestions welcome.
> >
> >
> >> On Sep 22, 2017, at 9:07 AM, Josh Elser  wrote:
> >>
> >> I can appreciate how we've gotten to this point, it just struck me
> extremely odd that the contents of a Tag weren't expected to be accessed by
> users. "Arbitrary metadata that rides along with a cell, you just can't see
> that metadata" ;)
> >>
> >> I totally understand not wanting to let another thing come into 2.0.
> Like MikeD said, let's hope for a faster 3.0 and we can slate this for that
> time.
> >>
> >> Thanks for entertaining the discussion. We'll just deal with the
> "downstream pain" for 2.0.
> >>
> >>> On 9/22/17 1:32 AM, ramkrishna vasudevan wrote:
> >>> CellUtil  similar type of methods. Coming to Tags yes there are not
> much
> >>> cases where clients can directly set Tags. And I think we don't expose
> any
> >>> APIs which allow you to use mutations with Tags. So probably moving to
> >>> LimitedPrivate is better and mark with Evolving if there are some users
> >>> depending on the internals of Tags and its impl. But this will be a
> One of
> >>> case.
> >>> And also since Tags are internal ideally the CellUtil#getTAgs() should
> have
> >>> been in another Util method that is exposed with LimitedPrivate and
> also
> >>> Tags if tags should be made LimitedPRivate. So this may help in not
> having
> >>> a PRivate interface like Tag in a public CellUtil class.
> >>> 3.0 is fine but need some clean up in 2.0? Indicating what could happen
> >>> going forward from 2.0?
> >>> Regards
> >>> Ram
>  On Fri, Sep 22, 2017 at 2:59 AM, Sean Busbey 
> wrote:
>  Yeah. I mean, I think we should improve  the situation. Just think
>  it's too much to bite off at this stage of 2.0, we can aim for 3.0 and
>  start working in some tooling to help us.
> 
> > On Thu, Sep 21, 2017 at 3:35 PM, Josh Elser 
> wrote:
> > That really makes me groan (we have downstream users depending on
> code
>  we've
> > explicitly said "don't use"), but if that's what it is given the
> current
> > state, so be it. My complaining won't fix it.
> >
> > Thanks.
> >
> >
> >> On 9/21/17 4:25 PM, Sean Busbey wrote:
> >>
> >> We have lots of examples of including non-Public stuff in Public
> APIs.
> >> we have docs that advise folks to be wary on relying on them beyond
> >> opaque symbols.
> >>
> >> ref: http://hbase.apache.org/book.html#hbase.client.api.surface
> >>
> >>> On Thu, Sep 21, 2017 at 3:21 PM, Josh Elser 
> wrote:
> >>>
> >>> I was going to suggest LimitedPrivate in my original, but this
> doesn't
> >>> make
> >>> sense as we're exposing Public API via CellUtil.
> >>>
> >>> It seems odd to me that we wouldn't treat the cell tags as a
> supported
> >>> API
> >>> call. However, I'm happy to remain "confused" if the rest of folks
>  don't
> >>> consider tags to be intended for users :)
> >>>
> >>>
>  On 9/21/17 3:15 PM, Ted Yu wrote:
> 
> 
>  Can we mark Tag LimitedPrivate ?
> 
>  We know how ATS uses Tags so it should be straight forward to keep
>  their
>  usage intact.
> 
>  On Thu, Sep 21, 2017 at 12:03 PM, Josh Elser 
>  wrote:
> 
> > Hiya,
> >
> > (Background, I'm starting what is likely to be an onerous task of
> > looking
> > through downstream components and seeing what is broken with the
>  latest
> > hbase-2.0.0*)
> >
> > Looking at YARN's use of HBase for the Application
> TimelineServer, I
> > see
> > that they're relying on the Tag interface.
> >
> > Presently, Tag is marked as Private, yet we expose it via the
> Public
> > CellUtil.
> >
> > My gut reaction is that we should bump Tag up Public since the
> intent
> 

Re: libsasl2.so.3 (branch HBASE-14850)

[Andrzej]

W dniu 22.09.2017 o 18:19, Ted Yu pisze:

On my docker VM, I found the following:

/usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25
/usr/lib/x86_64-linux-gnu/libsasl2.so.2
/usr/local/lib/libsasl2.so.3.0.0
/usr/local/lib/libsasl2.so.3


In my docker:
root@securecluster:/usr/src/hbase/hbase-native-client# whereis  libsasl2
libsasl2: /usr/local/lib/libsasl2.so /usr/local/lib/libsasl2.la
root@securecluster:/usr/src/hbase/hbase-native-client# ls 
/usr/local/lib/libsasl*

/usr/local/lib/libsasl2.la  /usr/local/lib/libsasl2.so.3
/usr/local/lib/libsasl2.so  /usr/local/lib/libsasl2.so.3.0.0
root@securecluster:/usr/src/hbase/hbase-native-client#



Take a look at the first RUN command in:

hbase-native-client/docker-files/Dockerfile


FROM pjameson/buck-folly-watchman:20160511

ARG CC=/usr/bin/gcc-5
ARG CXX=/usr/bin/g++-5
ARG CFLAGS="-D_GLIBCXX_USE_CXX11_ABI=0 -fPIC -g -fno-omit-frame-pointer 
-O2 -pthread"
ARG CXXFLAGS="-D_GLIBCXX_USE_CXX11_ABI=0 -fPIC -g 
-fno-omit-frame-pointer -O2 -pthread"


ENV JAVA_HOME="/usr/lib/jvm/java-8-openjdk-amd64/"

RUN wget ftp://ftp.cyrusimap.org/cyrus-sasl/cyrus-sasl-2.1.26.tar.gz ; \
tar zxf cyrus-sasl-2.1.26.tar.gz ; \
cd cyrus-sasl-2.1.26 ; \
./configure ; \
make ; \
make install ;\
cp /usr/local/lib/sasl2/* /usr/lib/sasl2/


Similar to this RUN I must do outside docker?

Re: Please congratulate our new PMC Chair Misty Stanley-Jones

[Alexander Leblang]

Congrats Misty! Well done!
On Fri, Sep 22, 2017 at 11:25 AM Wei-Chiu Chuang  wrote:

> Congrats! Misty!!
>
> On Fri, Sep 22, 2017 at 7:50 AM, Jimmy Xiang  wrote:
>
> > Congrats! Misty!!
> >
> > On Fri, Sep 22, 2017 at 7:16 AM, Pankaj kr  wrote:
> >
> > > Congratulations Misty..!! :)
> > >
> > >
> > > -Pankaj-
> > >
> > >
> > > -Original Message-
> > > From: Andrew Purtell [mailto:apurt...@apache.org]
> > > Sent: Friday, September 22, 2017 3:08 AM
> > > To: dev@hbase.apache.org; u...@hbase.apache.org
> > > Subject: Please congratulate our new PMC Chair Misty Stanley-Jones
> > >
> > > At today's meeting of the Board, Special Resolution B changing the
> HBase
> > > project Chair to Misty Stanley-Jones was passed unanimously.
> > >
> > > Please join me in congratulating Misty on her new role!
> > >
> > > ​(If you need any help or advice please don't hesitate to ping me,
> Misty,
> > > but I suspect you'll do just fine and won't need it.)​
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> >
>
>
>
> --
> A very happy Hadoop contributor
>

Re: [DISCUSS] Increase stability on o.a.h.h.Tag?

[Andrew Purtell]

I think not making the relevant APIs LP(Coprocessor) was an oversight. In my 
opinion we should do that. I'm not sure about Public. We could do that too but 
somewhere we need to call out that coprocessors have access to tags, but not 
clients. (Tags are removed at RPC except for replication.) LP doesn't imply 
what Public might. 

> On Sep 22, 2017, at 9:11 AM, Andrew Purtell  wrote:
> 
> Tags are server side internal metadata. Some carry sensitive information like 
> labels. I guess this could appear odd if not around for discussion when they 
> were introduced. So what documentation can be improved to lessen the 
> surprise? Javadoc? Online book? A JIRA with suggestions welcome. 
> 
> 
>> On Sep 22, 2017, at 9:07 AM, Josh Elser  wrote:
>> 
>> I can appreciate how we've gotten to this point, it just struck me extremely 
>> odd that the contents of a Tag weren't expected to be accessed by users. 
>> "Arbitrary metadata that rides along with a cell, you just can't see that 
>> metadata" ;)
>> 
>> I totally understand not wanting to let another thing come into 2.0. Like 
>> MikeD said, let's hope for a faster 3.0 and we can slate this for that time.
>> 
>> Thanks for entertaining the discussion. We'll just deal with the "downstream 
>> pain" for 2.0.
>> 
>>> On 9/22/17 1:32 AM, ramkrishna vasudevan wrote:
>>> CellUtil  similar type of methods. Coming to Tags yes there are not much
>>> cases where clients can directly set Tags. And I think we don't expose any
>>> APIs which allow you to use mutations with Tags. So probably moving to
>>> LimitedPrivate is better and mark with Evolving if there are some users
>>> depending on the internals of Tags and its impl. But this will be a One of
>>> case.
>>> And also since Tags are internal ideally the CellUtil#getTAgs() should have
>>> been in another Util method that is exposed with LimitedPrivate and also
>>> Tags if tags should be made LimitedPRivate. So this may help in not having
>>> a PRivate interface like Tag in a public CellUtil class.
>>> 3.0 is fine but need some clean up in 2.0? Indicating what could happen
>>> going forward from 2.0?
>>> Regards
>>> Ram
 On Fri, Sep 22, 2017 at 2:59 AM, Sean Busbey  wrote:
 Yeah. I mean, I think we should improve  the situation. Just think
 it's too much to bite off at this stage of 2.0, we can aim for 3.0 and
 start working in some tooling to help us.
 
> On Thu, Sep 21, 2017 at 3:35 PM, Josh Elser  wrote:
> That really makes me groan (we have downstream users depending on code
 we've
> explicitly said "don't use"), but if that's what it is given the current
> state, so be it. My complaining won't fix it.
> 
> Thanks.
> 
> 
>> On 9/21/17 4:25 PM, Sean Busbey wrote:
>> 
>> We have lots of examples of including non-Public stuff in Public APIs.
>> we have docs that advise folks to be wary on relying on them beyond
>> opaque symbols.
>> 
>> ref: http://hbase.apache.org/book.html#hbase.client.api.surface
>> 
>>> On Thu, Sep 21, 2017 at 3:21 PM, Josh Elser  wrote:
>>> 
>>> I was going to suggest LimitedPrivate in my original, but this doesn't
>>> make
>>> sense as we're exposing Public API via CellUtil.
>>> 
>>> It seems odd to me that we wouldn't treat the cell tags as a supported
>>> API
>>> call. However, I'm happy to remain "confused" if the rest of folks
 don't
>>> consider tags to be intended for users :)
>>> 
>>> 
 On 9/21/17 3:15 PM, Ted Yu wrote:
 
 
 Can we mark Tag LimitedPrivate ?
 
 We know how ATS uses Tags so it should be straight forward to keep
 their
 usage intact.
 
 On Thu, Sep 21, 2017 at 12:03 PM, Josh Elser 
 wrote:
 
> Hiya,
> 
> (Background, I'm starting what is likely to be an onerous task of
> looking
> through downstream components and seeing what is broken with the
 latest
> hbase-2.0.0*)
> 
> Looking at YARN's use of HBase for the Application TimelineServer, I
> see
> that they're relying on the Tag interface.
> 
> Presently, Tag is marked as Private, yet we expose it via the Public
> CellUtil.
> 
> My gut reaction is that we should bump Tag up Public since the intent
> is
> for downstream users to, ya know, use those Tags. Any objections?
> 
> If we don't want to expose Tag, we should make a pass over the Public
> methods and mark them as Private (so not as to provide a Public
 method
> with
> Private objects). CellUtil#getTag(Cell, byte) would be one such
> example.
> 
> - Josh
> 
 
>>> 
> 
 

Re: libsasl2.so.3 (branch HBASE-14850)

[Ted Yu]

On my docker VM, I found the following:

/usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25
/usr/lib/x86_64-linux-gnu/libsasl2.so.2
/usr/local/lib/libsasl2.so.3.0.0
/usr/local/lib/libsasl2.so.3

Which commit were you using for the branch ?
I used:

21c08df9079b8cc9dd1c8c2208a7604fc12fca12

Take a look at the first RUN command in:

hbase-native-client/docker-files/Dockerfile

Cheers

On Fri, Sep 22, 2017 at 9:07 AM, Andrzej  wrote:

> I have build my own library bases on simple-client.
> When try run is error: libsasl2.so.3 cannot open shared object file no
> such file or directory
> I have libsasl2.so.2 and I don't know how install libsasl2.so.3
>

Re: [DISCUSS] Increase stability on o.a.h.h.Tag?

[Andrew Purtell]

Tags are server side internal metadata. Some carry sensitive information like 
labels. I guess this could appear odd if not around for discussion when they 
were introduced. So what documentation can be improved to lessen the surprise? 
Javadoc? Online book? A JIRA with suggestions welcome. 


> On Sep 22, 2017, at 9:07 AM, Josh Elser  wrote:
> 
> I can appreciate how we've gotten to this point, it just struck me extremely 
> odd that the contents of a Tag weren't expected to be accessed by users. 
> "Arbitrary metadata that rides along with a cell, you just can't see that 
> metadata" ;)
> 
> I totally understand not wanting to let another thing come into 2.0. Like 
> MikeD said, let's hope for a faster 3.0 and we can slate this for that time.
> 
> Thanks for entertaining the discussion. We'll just deal with the "downstream 
> pain" for 2.0.
> 
>> On 9/22/17 1:32 AM, ramkrishna vasudevan wrote:
>> CellUtil  similar type of methods. Coming to Tags yes there are not much
>> cases where clients can directly set Tags. And I think we don't expose any
>> APIs which allow you to use mutations with Tags. So probably moving to
>> LimitedPrivate is better and mark with Evolving if there are some users
>> depending on the internals of Tags and its impl. But this will be a One of
>> case.
>> And also since Tags are internal ideally the CellUtil#getTAgs() should have
>> been in another Util method that is exposed with LimitedPrivate and also
>> Tags if tags should be made LimitedPRivate. So this may help in not having
>> a PRivate interface like Tag in a public CellUtil class.
>> 3.0 is fine but need some clean up in 2.0? Indicating what could happen
>> going forward from 2.0?
>> Regards
>> Ram
>>> On Fri, Sep 22, 2017 at 2:59 AM, Sean Busbey  wrote:
>>> Yeah. I mean, I think we should improve  the situation. Just think
>>> it's too much to bite off at this stage of 2.0, we can aim for 3.0 and
>>> start working in some tooling to help us.
>>> 
 On Thu, Sep 21, 2017 at 3:35 PM, Josh Elser  wrote:
 That really makes me groan (we have downstream users depending on code
>>> we've
 explicitly said "don't use"), but if that's what it is given the current
 state, so be it. My complaining won't fix it.
 
 Thanks.
 
 
> On 9/21/17 4:25 PM, Sean Busbey wrote:
> 
> We have lots of examples of including non-Public stuff in Public APIs.
> we have docs that advise folks to be wary on relying on them beyond
> opaque symbols.
> 
> ref: http://hbase.apache.org/book.html#hbase.client.api.surface
> 
>> On Thu, Sep 21, 2017 at 3:21 PM, Josh Elser  wrote:
>> 
>> I was going to suggest LimitedPrivate in my original, but this doesn't
>> make
>> sense as we're exposing Public API via CellUtil.
>> 
>> It seems odd to me that we wouldn't treat the cell tags as a supported
>> API
>> call. However, I'm happy to remain "confused" if the rest of folks
>>> don't
>> consider tags to be intended for users :)
>> 
>> 
>>> On 9/21/17 3:15 PM, Ted Yu wrote:
>>> 
>>> 
>>> Can we mark Tag LimitedPrivate ?
>>> 
>>> We know how ATS uses Tags so it should be straight forward to keep
>>> their
>>> usage intact.
>>> 
>>> On Thu, Sep 21, 2017 at 12:03 PM, Josh Elser 
>>> wrote:
>>> 
 Hiya,
 
 (Background, I'm starting what is likely to be an onerous task of
 looking
 through downstream components and seeing what is broken with the
>>> latest
 hbase-2.0.0*)
 
 Looking at YARN's use of HBase for the Application TimelineServer, I
 see
 that they're relying on the Tag interface.
 
 Presently, Tag is marked as Private, yet we expose it via the Public
 CellUtil.
 
 My gut reaction is that we should bump Tag up Public since the intent
 is
 for downstream users to, ya know, use those Tags. Any objections?
 
 If we don't want to expose Tag, we should make a pass over the Public
 methods and mark them as Private (so not as to provide a Public
>>> method
 with
 Private objects). CellUtil#getTag(Cell, byte) would be one such
 example.
 
 - Josh
 
>>> 
>> 
 
>>> 

libsasl2.so.3 (branch HBASE-14850)

[Andrzej]

I have build my own library bases on simple-client.
When try run is error: libsasl2.so.3 cannot open shared object file no 
such file or directory

I have libsasl2.so.2 and I don't know how install libsasl2.so.3

Re: [DISCUSS] Increase stability on o.a.h.h.Tag?

[Josh Elser]

I can appreciate how we've gotten to this point, it just struck me 
extremely odd that the contents of a Tag weren't expected to be accessed 
by users. "Arbitrary metadata that rides along with a cell, you just 
can't see that metadata" ;)


I totally understand not wanting to let another thing come into 2.0. 
Like MikeD said, let's hope for a faster 3.0 and we can slate this for 
that time.


Thanks for entertaining the discussion. We'll just deal with the 
"downstream pain" for 2.0.


On 9/22/17 1:32 AM, ramkrishna vasudevan wrote:

CellUtil  similar type of methods. Coming to Tags yes there are not much
cases where clients can directly set Tags. And I think we don't expose any
APIs which allow you to use mutations with Tags. So probably moving to
LimitedPrivate is better and mark with Evolving if there are some users
depending on the internals of Tags and its impl. But this will be a One of
case.

And also since Tags are internal ideally the CellUtil#getTAgs() should have
been in another Util method that is exposed with LimitedPrivate and also
Tags if tags should be made LimitedPRivate. So this may help in not having
a PRivate interface like Tag in a public CellUtil class.

3.0 is fine but need some clean up in 2.0? Indicating what could happen
going forward from 2.0?

Regards
Ram



On Fri, Sep 22, 2017 at 2:59 AM, Sean Busbey  wrote:


Yeah. I mean, I think we should improve  the situation. Just think
it's too much to bite off at this stage of 2.0, we can aim for 3.0 and
start working in some tooling to help us.

On Thu, Sep 21, 2017 at 3:35 PM, Josh Elser  wrote:

That really makes me groan (we have downstream users depending on code

we've

explicitly said "don't use"), but if that's what it is given the current
state, so be it. My complaining won't fix it.

Thanks.


On 9/21/17 4:25 PM, Sean Busbey wrote:


We have lots of examples of including non-Public stuff in Public APIs.
we have docs that advise folks to be wary on relying on them beyond
opaque symbols.

ref: http://hbase.apache.org/book.html#hbase.client.api.surface

On Thu, Sep 21, 2017 at 3:21 PM, Josh Elser  wrote:


I was going to suggest LimitedPrivate in my original, but this doesn't
make
sense as we're exposing Public API via CellUtil.

It seems odd to me that we wouldn't treat the cell tags as a supported
API
call. However, I'm happy to remain "confused" if the rest of folks

don't

consider tags to be intended for users :)


On 9/21/17 3:15 PM, Ted Yu wrote:



Can we mark Tag LimitedPrivate ?

We know how ATS uses Tags so it should be straight forward to keep

their

usage intact.

On Thu, Sep 21, 2017 at 12:03 PM, Josh Elser 

wrote:



Hiya,

(Background, I'm starting what is likely to be an onerous task of
looking
through downstream components and seeing what is broken with the

latest

hbase-2.0.0*)

Looking at YARN's use of HBase for the Application TimelineServer, I
see
that they're relying on the Tag interface.

Presently, Tag is marked as Private, yet we expose it via the Public
CellUtil.

My gut reaction is that we should bump Tag up Public since the intent
is
for downstream users to, ya know, use those Tags. Any objections?

If we don't want to expose Tag, we should make a pass over the Public
methods and mark them as Private (so not as to provide a Public

method

with
Private objects). CellUtil#getTag(Cell, byte) would be one such
example.

- Josh

Re: Please congratulate our new PMC Chair Misty Stanley-Jones

[Wei-Chiu Chuang]

Congrats! Misty!!

On Fri, Sep 22, 2017 at 7:50 AM, Jimmy Xiang  wrote:

> Congrats! Misty!!
>
> On Fri, Sep 22, 2017 at 7:16 AM, Pankaj kr  wrote:
>
> > Congratulations Misty..!! :)
> >
> >
> > -Pankaj-
> >
> >
> > -Original Message-
> > From: Andrew Purtell [mailto:apurt...@apache.org]
> > Sent: Friday, September 22, 2017 3:08 AM
> > To: dev@hbase.apache.org; u...@hbase.apache.org
> > Subject: Please congratulate our new PMC Chair Misty Stanley-Jones
> >
> > At today's meeting of the Board, Special Resolution B changing the HBase
> > project Chair to Misty Stanley-Jones was passed unanimously.
> >
> > Please join me in congratulating Misty on her new role!
> >
> > ​(If you need any help or advice please don't hesitate to ping me, Misty,
> > but I suspect you'll do just fine and won't need it.)​
> >
> >
> > --
> > Best regards,
> > Andrew
> >
>



-- 
A very happy Hadoop contributor

Re: Please congratulate our new PMC Chair Misty Stanley-Jones

[Jimmy Xiang]

Congrats! Misty!!

On Fri, Sep 22, 2017 at 7:16 AM, Pankaj kr  wrote:

> Congratulations Misty..!! :)
>
>
> -Pankaj-
>
>
> -Original Message-
> From: Andrew Purtell [mailto:apurt...@apache.org]
> Sent: Friday, September 22, 2017 3:08 AM
> To: dev@hbase.apache.org; u...@hbase.apache.org
> Subject: Please congratulate our new PMC Chair Misty Stanley-Jones
>
> At today's meeting of the Board, Special Resolution B changing the HBase
> project Chair to Misty Stanley-Jones was passed unanimously.
>
> Please join me in congratulating Misty on her new role!
>
> ​(If you need any help or advice please don't hesitate to ping me, Misty,
> but I suspect you'll do just fine and won't need it.)​
>
>
> --
> Best regards,
> Andrew
>

RE: Please congratulate our new PMC Chair Misty Stanley-Jones

[Pankaj kr]

Congratulations Misty..!! :)


-Pankaj-


-Original Message-
From: Andrew Purtell [mailto:apurt...@apache.org] 
Sent: Friday, September 22, 2017 3:08 AM
To: dev@hbase.apache.org; u...@hbase.apache.org
Subject: Please congratulate our new PMC Chair Misty Stanley-Jones

At today's meeting of the Board, Special Resolution B changing the HBase 
project Chair to Misty Stanley-Jones was passed unanimously.

Please join me in congratulating Misty on her new role!

​(If you need any help or advice please don't hesitate to ping me, Misty, but I 
suspect you'll do just fine and won't need it.)​


--
Best regards,
Andrew

Re: How force rebuild with buck on docker?

[Ted Yu]

Have you tried removing buck-out directory (under hbase-native-client) ?

On Fri, Sep 22, 2017 at 7:01 AM, Andrzej  wrote:

> W dniu 05.09.2017 o 17:25, Ted Yu pisze:
>
>> Have you tried running the following command ?
>>
>> buck clean
>>
>
> Nothing helps, removed megabytes but not forces to rebuild
>

Re: How force rebuild with buck on docker?

[Andrzej]

W dniu 05.09.2017 o 17:25, Ted Yu pisze:

Have you tried running the following command ?

buck clean


Nothing helps, removed megabytes but not forces to rebuild

[jira] [Created] (HBASE-18864) NullPointerException thrown when adding rows to a table from peer cluster, table with replication factor other than 0 or 1

[smita (JIRA)]

smita created HBASE-18864:
-

 Summary: NullPointerException thrown when adding rows to a table 
from peer cluster, table with replication factor other than 0 or 1
 Key: HBASE-18864
 URL: https://issues.apache.org/jira/browse/HBASE-18864
 Project: HBase
  Issue Type: Bug
  Components: hbase
Affects Versions: 1.3.0
Reporter: smita


Scenario:
=
add_peer
create a table
alter table with REPLICATION_SCOPE => '5'
enable table replication
login to peer cluster and try putting data to the table 




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

Re:Re: Please congratulate our new PMC Chair Misty Stanley-Jones

[Chunhui Shen]

Congrats Misty!
At 2017-09-22 15:25:18, "Jingcheng Du"  wrote:
>Congratulations, Misty!
>
>2017-09-22 15:10 GMT+08:00 ashish singhi :
>
>> Many Congratulations for the new role, Misty.
>>
>> -Original Message-
>> From: Andrew Purtell [mailto:apurt...@apache.org]
>> Sent: 22 September 2017 00:38
>> To: dev@hbase.apache.org; u...@hbase.apache.org
>> Subject: Please congratulate our new PMC Chair Misty Stanley-Jones
>>
>> At today's meeting of the Board, Special Resolution B changing the HBase
>> project Chair to Misty Stanley-Jones was passed unanimously.
>>
>> Please join me in congratulating Misty on her new role!
>>
>> (If you need any help or advice please don't hesitate to ping me, Misty,
>> but I suspect you'll do just fine and won't need it.)
>>
>>
>> --
>> Best regards,
>> Andrew
>>

[jira] [Created] (HBASE-18863) spark over hbase snapshot

[ulysses you (JIRA)]

ulysses you created HBASE-18863:
---

 Summary: spark over hbase snapshot
 Key: HBASE-18863
 URL: https://issues.apache.org/jira/browse/HBASE-18863
 Project: HBase
  Issue Type: Bug
  Components: Client, snapshots, spark
Affects Versions: 1.2.0
Reporter: ulysses you


The configuration error in two method. First is ok, and second is wrong.

{code:java}
1.
val hConf = HBaseConfiguration.create()
// ignore some config

val hBaseRDD = sc.newAPIHadoopRDD(hConf,
  classOf[TableSnapshotInputFormat],
  classOf[org.apache.hadoop.hbase.io.ImmutableBytesWritable],
  classOf[org.apache.hadoop.hbase.client.Result])
2.
val hConf = HBaseConfiguration.create()
val job = Job.getInstance(hConf)
val hBaseRDD = sc.newAPIHadoopRDD(job.getConfiguration,
  classOf[TableSnapshotInputFormat],
  classOf[org.apache.hadoop.hbase.io.ImmutableBytesWritable],
  classOf[org.apache.hadoop.hbase.client.Result])

and the log:
Caused by: java.lang.ClassNotFoundException: 
org.apache.hadoop.hbase.codec.prefixtree.PrefixTreeCodec
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at 
org.apache.hadoop.hbase.io.encoding.DataBlockEncoding.createEncoder(DataBlockEncoding.java:186)
... 21 more
{code}


I'm sure that I have upload jar with spark cmd -jars.
Is this a bug?



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

[jira] [Created] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3

[Yechao Chen (JIRA)]

Yechao Chen created HBASE-18862:
---

 Summary: apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
 Key: HBASE-18862
 URL: https://issues.apache.org/jira/browse/HBASE-18862
 Project: HBase
  Issue Type: Bug
Reporter: Yechao Chen
Assignee: Yechao Chen


HBASE-15109 should apply to  branch-1.1,branch-1.2,branch-1.3 also.




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

Re: Please congratulate our new PMC Chair Misty Stanley-Jones

[Jingcheng Du]

Congratulations, Misty!

2017-09-22 15:10 GMT+08:00 ashish singhi :

> Many Congratulations for the new role, Misty.
>
> -Original Message-
> From: Andrew Purtell [mailto:apurt...@apache.org]
> Sent: 22 September 2017 00:38
> To: dev@hbase.apache.org; u...@hbase.apache.org
> Subject: Please congratulate our new PMC Chair Misty Stanley-Jones
>
> At today's meeting of the Board, Special Resolution B changing the HBase
> project Chair to Misty Stanley-Jones was passed unanimously.
>
> Please join me in congratulating Misty on her new role!
>
> ​(If you need any help or advice please don't hesitate to ping me, Misty,
> but I suspect you'll do just fine and won't need it.)​
>
>
> --
> Best regards,
> Andrew
>

RE: Please congratulate our new PMC Chair Misty Stanley-Jones

[ashish singhi]

Many Congratulations for the new role, Misty.

-Original Message-
From: Andrew Purtell [mailto:apurt...@apache.org] 
Sent: 22 September 2017 00:38
To: dev@hbase.apache.org; u...@hbase.apache.org
Subject: Please congratulate our new PMC Chair Misty Stanley-Jones

At today's meeting of the Board, Special Resolution B changing the HBase 
project Chair to Misty Stanley-Jones was passed unanimously.

Please join me in congratulating Misty on her new role!

​(If you need any help or advice please don't hesitate to ping me, Misty, but I 
suspect you'll do just fine and won't need it.)​


--
Best regards,
Andrew

Re: Please congratulate our new PMC Chair Misty Stanley-Jones

[Allan Yang]

Congratulations, Misty!

Best Regards
Allan Yang

2017-09-22 13:40 GMT+08:00 ramkrishna vasudevan <
ramkrishna.s.vasude...@gmail.com>:

> Congratulations Misty !!!
>
> On Fri, Sep 22, 2017 at 11:06 AM, Huaxiang Sun  wrote:
>
> > Congratulations Misty!
> >
> > Huaxiang
> >
> > > On Sep 21, 2017, at 9:51 PM, Yu Li  wrote:
> > >
> > > Congrats Misty!
> > >
> > > Best Regards,
> > > Yu
> > >
> > > On 22 September 2017 at 11:26, Guanghao Zhang 
> > wrote:
> > >
> > >> Congratulations!
> > >>
> > >> 2017-09-22 11:20 GMT+08:00 Chia-Ping Tsai :
> > >>
> > >>> congrats Misty!!!
> > >>>
> > >>> On 2017-09-22 03:08, Andrew Purtell  wrote:
> >  At today's meeting of the Board, Special Resolution B changing the
> > >> HBase
> >  project Chair to Misty Stanley-Jones was passed unanimously.
> > 
> >  Please join me in congratulating Misty on her new role!
> > 
> >  ​(If you need any help or advice please don't hesitate to ping me,
> > >> Misty,
> >  but I suspect you'll do just fine and won't need it.)​
> > 
> > 
> >  --
> >  Best regards,
> >  Andrew
> > 
> > >>>
> > >>
> >
> >
>