Re: Master branch does not compile

2020-06-19 Thread Guanghao Zhang 
>
> HBase 2.2 , which is a stable 2.x release ?


Yes, the stable release pointer is 2.2.x now. See
http://hbase.apache.org/downloads.html

Josh Elser  于2020年6月20日周六 上午2:08写道：

> I see no value in supporting 2.0. I have mixed feelings on 2.1. We
> should default to 2.2, especially with 2.3 releases incoming "soon".
>
> We're in a good position to help HBase drive adoption of certain
> versions. While this is always sort of "implicit" (it just happens), I
> see value in it via advertising what users should pick up.
>
> On 6/17/20 8:42 AM, cheng...@apache.org wrote:
> >
> >
> >
> > Should we only support HBase 2.2 , which is a stable 2.x release ?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > At 2020-06-17 16:04:58, "Istvan Toth"  wrote:
> >> The 4.x branch has historically deprecated unsupported branches.
> >>
> >> I'd be fine with removing support for EOL 2.x branches in master,
> >> https://issues.apache.org/jira/browse/PHOENIX-5716 is open for this
> very
> >> issue,
> >> but would welcome some community input before working on it.
> >>
> >> I also like Josh's idea,
> https://issues.apache.org/jira/browse/PHOENIX-5828 is
> >> quite similar to it.
> >>
> >>
> >> On Wed, Jun 17, 2020 at 2:49 AM Guanghao Zhang 
> wrote:
> >>
> >>> HBase 2.0 and 2.1 has been EOL now. Does phoenix need to support them?
> >>>
> >>> swaroopa kadam  于2020年6月17日周三 上午12:32写道：
> >>>
>  yes, that’s a good idea.
> 
>  On Tue, Jun 16, 2020 at 9:29 AM Josh Elser  wrote:
> 
> > Sounds like we should try to update precommit to at least compile
> > against _a version_ in each line 2.1/2.2/2.3 for master. Thoughts?
> >
> > On 6/16/20 11:57 AM, swaroopa kadam wrote:
> >> Thank you for the replies everyone!
> >>
> >> It puts me at ease by knowing the issue has been identified and
> being
> >> fixed.
> >>
> >> Thanks!
> >>
> >> On Tue, Jun 16, 2020 at 4:11 AM rajeshb...@apache.org <
> >> chrajeshbab...@gmail.com> wrote:
> >>
> >>> I am on the PHOENIX-5905 compilation issue and will fix it today.
> >>>
> >>> On Tue, Jun 16, 2020 at 3:07 PM cheng...@apache.org <
> > cheng...@apache.org>
> >>> wrote:
> >>>
> 
> 
> 
>  PHOENIX-5905 caused the master branch compile broken, because
>  org.apache.hadoop.hbase.security.access.GetUserPermissionsRequest
> >>> is
> > only
>  available in hbase 2.2.x,
>  so when the hbase.profile=2.0 or  hbase.profile=2.1, the compiler
> > boken,
>  Should we revert PHOENIX-5905 for the moment?
> 
> 
>  The error messages are :
> 
> 
>  [ERROR] COMPILATION ERROR :
>  [INFO]
> >>> -
>  [ERROR] <
> 
> >>>
> >
> 
> >>>
> https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java
>  :[39,47]
>  cannot find symbol
>  symbol:   class GetUserPermissionsRequest
>  location: package org.apache.hadoop.hbase.security.access
>  [ERROR] <
> 
> >>>
> >
> 
> >>>
> https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java
>  :[1452,48]
>  cannot find symbol
>  symbol:   method hasUserName()
>  location: variable request of type
> 
> >>>
> >
> 
> >>>
> org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
>  [ERROR] <
> 
> >>>
> >
> 
> >>>
> https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java
>  :[1452,72]
>  cannot find symbol
>  symbol:   method getUserName()
>  location: variable request of type
> 
> >>>
> >
> 
> >>>
> org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
>  [ERROR] <
> 
> >>>
> >
> 
> >>>
> https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java
>  :[1458,32]
>  cannot find symbol
>  symbol:   method hasColumnFamily()
>  location: variable request of type
> 
> >>>
> >
> 
> >>>
> org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
>  [ERROR] <
> 
> >>>
> >
> 
> >>>
> https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java
>  :[1458,60]
>  cannot find symbol
>  symbol:   method

[jira] [Created] (PHOENIX-5967) phoenix-client transitively pulling in phoenix-core

2020-06-19 Thread Josh Elser (Jira) 
Josh Elser created PHOENIX-5967:
---

 Summary: phoenix-client transitively pulling in phoenix-core
 Key: PHOENIX-5967
 URL: https://issues.apache.org/jira/browse/PHOENIX-5967
 Project: Phoenix
  Issue Type: Bug
Reporter: Josh Elser
Assignee: Josh Elser


Looks like something happened in master where phoenix-client is now 
transitively pulling in phoenix-core, even though all of phoenix-core and its 
dependencies are included in the phoenix-client shaded artifact.

4.15.0 looks OK, so maybe something inadvertent with the hbase version 
classifier stuff, [~stoty]?



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

Re: [DISCUSS] Renaming phoenix-queryserver maven artifacts (and jars)

2020-06-19 Thread Josh Elser 
Fine by me. I think keeping `phoenix-queryserver-client` the same is the 
one that's most important. However, since the move to the separate repo 
and that we've not had a real release from it yet, we have the 
flexibility to make the change now.


On 6/19/20 3:31 AM, Istvan Toth wrote:

Hi!

I'd like to change the phoenix-queryserver artifact  and jar names, and
possibly rename the subproject directories as well:

This is what I have in mind:

phoenix-queryserver-parent
phoenix-queryserver-assembly
phoenix-queryserver-load-balancer
phoenix-queryserver
phoenix-queryserver-client
phoenix-queryerrver-it
phoenix-queryserver-orchestrator

This would match the pre-unbundling artifact names for the client and
server,
follow the hadoop conventions, and make the resulting JARs easily
identifiable.

I've opened https://issues.apache.org/jira/browse/PHOENIX-5964 for this.

Since this is a highly visible change, I'd like to have some feedback from
the community before committing to this.

Since we haven't made a release yet, this would be a great time to get this
in order.

looking forward to hearing from you

Istvan

Re: Master branch does not compile

2020-06-19 Thread Josh Elser 
I see no value in supporting 2.0. I have mixed feelings on 2.1. We 
should default to 2.2, especially with 2.3 releases incoming "soon".


We're in a good position to help HBase drive adoption of certain 
versions. While this is always sort of "implicit" (it just happens), I 
see value in it via advertising what users should pick up.


On 6/17/20 8:42 AM, cheng...@apache.org wrote:




Should we only support HBase 2.2 , which is a stable 2.x release ?














At 2020-06-17 16:04:58, "Istvan Toth"  wrote:

The 4.x branch has historically deprecated unsupported branches.

I'd be fine with removing support for EOL 2.x branches in master,
https://issues.apache.org/jira/browse/PHOENIX-5716 is open for this very
issue,
but would welcome some community input before working on it.

I also like Josh's idea, https://issues.apache.org/jira/browse/PHOENIX-5828 is
quite similar to it.


On Wed, Jun 17, 2020 at 2:49 AM Guanghao Zhang  wrote:


HBase 2.0 and 2.1 has been EOL now. Does phoenix need to support them?

swaroopa kadam  于2020年6月17日周三 上午12:32写道：


yes, that’s a good idea.

On Tue, Jun 16, 2020 at 9:29 AM Josh Elser  wrote:


Sounds like we should try to update precommit to at least compile
against _a version_ in each line 2.1/2.2/2.3 for master. Thoughts?

On 6/16/20 11:57 AM, swaroopa kadam wrote:

Thank you for the replies everyone!

It puts me at ease by knowing the issue has been identified and being
fixed.

Thanks!

On Tue, Jun 16, 2020 at 4:11 AM rajeshb...@apache.org <
chrajeshbab...@gmail.com> wrote:


I am on the PHOENIX-5905 compilation issue and will fix it today.

On Tue, Jun 16, 2020 at 3:07 PM cheng...@apache.org <

cheng...@apache.org>

wrote:





PHOENIX-5905 caused the master branch compile broken, because
org.apache.hadoop.hbase.security.access.GetUserPermissionsRequest

is

only

available in hbase 2.2.x,
so when the hbase.profile=2.0 or  hbase.profile=2.1, the compiler

boken,

Should we revert PHOENIX-5905 for the moment?


The error messages are :


[ERROR] COMPILATION ERROR :
[INFO]

-

[ERROR] <








https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java

:[39,47]
cannot find symbol
symbol:   class GetUserPermissionsRequest
location: package org.apache.hadoop.hbase.security.access
[ERROR] <








https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java

:[1452,48]
cannot find symbol
symbol:   method hasUserName()
location: variable request of type








org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest

[ERROR] <








https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java

:[1452,72]
cannot find symbol
symbol:   method getUserName()
location: variable request of type








org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest

[ERROR] <








https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java

:[1458,32]
cannot find symbol
symbol:   method hasColumnFamily()
location: variable request of type








org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest

[ERROR] <








https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java

:[1458,60]
cannot find symbol
symbol:   method getColumnFamily()
location: variable request of type








org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest

[ERROR] <








https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java

:[1460,32]
cannot find symbol
symbol:   method hasColumnQualifier()
location: variable request of type








org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest

[ERROR] <








https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java

:[1460,63]
cannot find symbol
symbol:   method getColumnQualifier()
location: variable request of type








org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest

[ERROR] <








https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java

:[1461,17]
cannot find symbol
symbol:   class GetUserPermissionsRequest
location: class
org.apache.phoenix.end2end.BasePermissionsIT.CustomAccessController
[ERROR] <

[jira] [Created] (PHOENIX-5966) Include poms in embedded maven repo

2020-06-19 Thread Josh Elser (Jira) 
Josh Elser created PHOENIX-5966:
---

 Summary: Include poms in embedded maven repo
 Key: PHOENIX-5966
 URL: https://issues.apache.org/jira/browse/PHOENIX-5966
 Project: Phoenix
  Issue Type: Improvement
Reporter: Josh Elser
Assignee: Josh Elser
 Fix For: 1.0.0


[~psomogyi] happened to notice that the embedded maven repo doesn't have 
pom.xml's copied into it by the dependency-plugin. There's an option for this, 
but it's false by default. Without these, pulling the artifacts for the n+1'th 
time fails (as maven can't check its freshness).



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

[jira] [Updated] (PHOENIX-5779) SplitSystemCatalogIT tests fail with Multiple Regions error

2020-06-19 Thread Richard Antal (Jira) 


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

Richard Antal updated PHOENIX-5779:
---
Summary: SplitSystemCatalogIT tests fail with Multiple Regions error  (was: 
SpliitSystemCatalogIT tests fail with Multiple Regions error)

> SplitSystemCatalogIT tests fail with Multiple Regions error
> ---
>
> Key: PHOENIX-5779
> URL: https://issues.apache.org/jira/browse/PHOENIX-5779
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 5.1.0
>Reporter: Sandeep Guggilam
>Priority: Major
>
> I see the SplitSystemCatalogIT tests failing on master branch complaining 
> with the error " Multiple regions on server" when it tries to split the 
> system catalog.
>  
> Sample builds where it failed:
> [https://builds.apache.org/job/PreCommit-PHOENIX-Build/3560//testReport/]
> [https://builds.apache.org/job/PreCommit-PHOENIX-Build/3571//testReport/]
>  



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

[DISCUSS] Renaming phoenix-queryserver maven artifacts (and jars)

2020-06-19 Thread Istvan Toth 
Hi!

I'd like to change the phoenix-queryserver artifact  and jar names, and
possibly rename the subproject directories as well:

This is what I have in mind:

phoenix-queryserver-parent
phoenix-queryserver-assembly
phoenix-queryserver-load-balancer
phoenix-queryserver
phoenix-queryserver-client
phoenix-queryerrver-it
phoenix-queryserver-orchestrator

This would match the pre-unbundling artifact names for the client and
server,
follow the hadoop conventions, and make the resulting JARs easily
identifiable.

I've opened https://issues.apache.org/jira/browse/PHOENIX-5964 for this.

Since this is a highly visible change, I'd like to have some feedback from
the community before committing to this.

Since we haven't made a release yet, this would be a great time to get this
in order.

looking forward to hearing from you

Istvan

[jira] [Updated] (PHOENIX-5964) Rename queryserver subprojects

2020-06-19 Thread Istvan Toth (Jira) 


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

Istvan Toth updated PHOENIX-5964:
-
Description: 
The current phoenix-queryserver maven subproject/artifact names are quite 
arbitrary and inconsistent.

The current structure:
phoenix-queryserver
assembly
load-balancer
queryserver
queryserver-client
queryerrver-it
queryserver-orchestrator

I propose that we change this to either:

phoenix-queryserver
queryserver-assembly
queryserver-load-balancer
queryserver
queryserver-client
queryerrver-it
queryserver-orchestrator

or

phoenix-queryserver-parent
phoenix-queryserver-assembly
phoenix-queryserver-load-balancer
phoenix-queryserver
phoenix-queryserver-client
phoenix-queryerrver-it
phoenix-queryserver-orchestrator

The latter is more consistent with hadoop conventions, and the pre-split 
artifact names, and matches the pre-unbundling artifact names better, but is 
also quite long.


  was:
The current phoenix-queryserver maven subproject/artifact names are quite 
arbitrary and inconsistent.

The current structure:
phoenix-queryserver
assembly
load-balancer
queryserver
queryserver-client
queryerrver-it
queryserver-orchestrator

I propose that we change this to either:

phoenix-queryserver
queryserver-assembly
queryserver-load-balancer
queryserver
queryserver-client
queryerrver-it
queryserver-orchestrator

or

phoenix-queryserver-parent
phoenix-queryserver-assembly
phoenix-queryserver-load-balancer
phoenix-queryserver
phoenix-queryserver-client
phoenix-queryerrver-it
phoenix-queryserver-orchestrator

The latter is more consistent with hadoop conventions, and the pre-split 
artifact names, but is also quite long.



> Rename queryserver subprojects
> --
>
> Key: PHOENIX-5964
> URL: https://issues.apache.org/jira/browse/PHOENIX-5964
> Project: Phoenix
>  Issue Type: Improvement
>  Components: queryserver
>Affects Versions: queryserver-1.0.0
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
>
> The current phoenix-queryserver maven subproject/artifact names are quite 
> arbitrary and inconsistent.
> The current structure:
> phoenix-queryserver
> assembly
> load-balancer
> queryserver
> queryserver-client
> queryerrver-it
> queryserver-orchestrator
> I propose that we change this to either:
> phoenix-queryserver
> queryserver-assembly
> queryserver-load-balancer
> queryserver
> queryserver-client
> queryerrver-it
> queryserver-orchestrator
> or
> phoenix-queryserver-parent
> phoenix-queryserver-assembly
> phoenix-queryserver-load-balancer
> phoenix-queryserver
> phoenix-queryserver-client
> phoenix-queryerrver-it
> phoenix-queryserver-orchestrator
> The latter is more consistent with hadoop conventions, and the pre-split 
> artifact names, and matches the pre-unbundling artifact names better, but is 
> also quite long.



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

Re: No builds on Phoenix-Master jenkins since Feb 19th?

2020-06-19 Thread Istvan Toth 
The hanging test suite issue has been fixed by Richard Antal's PHOENIX-5962
 .
Tests should be back to normal (that is, they're still flakey as fresh snow)

Rajeshbabu, is there an easy way (specific message in the logs) for
identifying the ZK connection exhaustion situation?

Istvan

On Thu, Jun 18, 2020 at 2:49 AM rajeshb...@apache.org <
chrajeshbab...@gmail.com> wrote:

> Just my observation related tests hang or flaky ness is that when there are
> connections created which involves zookeeper connection then at some point
> of time zookeeper sees too many connections and not allow to create further
> connections then the cluster won't be terminated immediately and tests
> hangs. We can identify such cases and close the connections properly if
> any.
>
> Thanks,
> Rajeshbabu.
>
> On Tue, Jun 16, 2020, 12:12 PM Istvan Toth  wrote:
>
> > What we really need is getting our test suite (and infra) sorted out.
> > Your suggestions are already part of the process, it's just that lately
> > everyone ignores them, because the precommit tests have been next to
> > useless for a good while.
> >
> > I think that if developers can be reasonably sure that the precommit
> > failure that they see is not some kind of random/known flake, they (we)
> > will take them seriously, and not commit until they(we) get it right.
> >
> > Blocking further commits until the tests are fixed is one drastic, but
> > possibly necessary measure to achieve this.
> > And once we get them fixed, we will indeed need to be more vigilant in
> not
> > letting the situation deteriorate.
> >
> > Istvan
> >
> > On Mon, Jun 15, 2020 at 7:30 PM Andrew Purtell 
> > wrote:
> >
> > > So it's time to enforce an automatic revert if build fails policy?
> > > Ideally, no commit before a precommit passes.
> > > If that fails, if someone discovers failing tests and can git bisect to
> > the
> > > cause, automatic revert of the offending commit.
> > >
> > > YDYT?
> > >
> > >
> > > On Sun, Jun 14, 2020 at 10:20 PM Istvan Toth
>  > >
> > > wrote:
> > >
> > > > Unfortunately you are not missing anything, Lars :(
> > > >
> > > > What's worse, the tests are not only failing, they even hang since
> Jun
> > 2.
> > > > Master is in a similar state.
> > > >
> > > > regards
> > > > Istvan
> > > >
> > > > On Sun, Jun 14, 2020 at 12:03 AM la...@apache.org 
> > > > wrote:
> > > >
> > > > > Thanks Istvan.
> > > > >
> > > > > Just checked the builds. Looks like the 4.x builds have not passed
> a
> > > > > single time since May 20th.
> > > > >
> > > > > I hope I am missing something... Otherwise this would be pretty
> > > > > frustrating. :)
> > > > > (Since pleading doesn't appear to help, maybe we should
> automatically
> > > > > block all commits until all tests pass...?)
> > > > >
> > > > > -- Lars
> > > > >
> > > > >
> > > > > On Tuesday, April 21, 2020, 5:33:52 AM PDT, Istvan Toth <
> > > > st...@apache.org>
> > > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I've deleted all but the four Phoenix jobs listed in the JIRA.
> > > > >
> > > > >
> > > >
> > > > --
> > > > *István Tóth* | Staff Software Engineer
> > > > st...@cloudera.com 
> > > > [image: Cloudera] 
> > > > [image: Cloudera on Twitter]  [image:
> > > > Cloudera on Facebook]  [image:
> > > Cloudera
> > > > on LinkedIn] 
> > > > 
> > > > --
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >- A23, Crosstalk
> > >
> >
>