[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[ https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15480105#comment-15480105 ] Hudson commented on HBASE-16576: FAILURE: Integrated in Jenkins build HBase-0.98-on-Hadoop-1.1 #1273 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/1273/]) HBASE-16576 Shell add_peer doesn't allow setting cluster_key for custom (apurtell: rev 78b036304356b2e4da6c57bad01fc1ce228e4041) * (edit) hbase-shell/src/main/ruby/shell/commands/add_peer.rb * (edit) hbase-shell/src/main/ruby/hbase/replication_admin.rb * (edit) hbase-shell/src/test/ruby/hbase/replication_admin_test.rb > Shell add_peer doesn't allow setting cluster_key for custom endpoints > - > > Key: HBASE-16576 > URL: https://issues.apache.org/jira/browse/HBASE-16576 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.0.0, 1.1.5, 0.98.22 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 2.0.0, 1.4.0, 0.98.23 > > Attachments: HBASE-16576-0.98.patch, HBASE-16576.patch, > HBASE-16576.v1.patch > > > The HBase shell allows a user to create a replication peer using the add_peer > method, which can take a peer id and a Ruby hash. It creates a > ReplicationPeerConfig and passes it through to the Java > ReplicationAdmin#addPeer. > The Ruby code makes an assumption that the Java API doesn't: that CLUSTER_KEY > and ENDPOINT_CLASSNAME are mutually exclusive. If both are specified, it > throws an error. If only ENDPOINT_CLASSNAME is set, the add_peer logic > derives a local dummy cluster key based on the local cluster's configuration. > CLUSTER_KEY shouldn't be required when an ENDPOINT_CLASSNAME is specified, > because a custom endpoint might not need it. The dummy default logic is fine. > > But if an endpoint does require a remote cluster key, it shouldn't be > forbidden to provide one, especially since the Java API permits it, and even > the custom replication endpoint Java tests rely on this. (See > TestReplicationEndpoint#testCustomReplicationEndpoint) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[ https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15479762#comment-15479762 ] Hudson commented on HBASE-16576: FAILURE: Integrated in Jenkins build HBase-0.98-matrix #400 (See [https://builds.apache.org/job/HBase-0.98-matrix/400/]) HBASE-16576 Shell add_peer doesn't allow setting cluster_key for custom (apurtell: rev 78b036304356b2e4da6c57bad01fc1ce228e4041) * (edit) hbase-shell/src/main/ruby/shell/commands/add_peer.rb * (edit) hbase-shell/src/test/ruby/hbase/replication_admin_test.rb * (edit) hbase-shell/src/main/ruby/hbase/replication_admin.rb > Shell add_peer doesn't allow setting cluster_key for custom endpoints > - > > Key: HBASE-16576 > URL: https://issues.apache.org/jira/browse/HBASE-16576 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.0.0, 1.1.5, 0.98.22 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 2.0.0, 1.4.0, 0.98.23 > > Attachments: HBASE-16576-0.98.patch, HBASE-16576.patch, > HBASE-16576.v1.patch > > > The HBase shell allows a user to create a replication peer using the add_peer > method, which can take a peer id and a Ruby hash. It creates a > ReplicationPeerConfig and passes it through to the Java > ReplicationAdmin#addPeer. > The Ruby code makes an assumption that the Java API doesn't: that CLUSTER_KEY > and ENDPOINT_CLASSNAME are mutually exclusive. If both are specified, it > throws an error. If only ENDPOINT_CLASSNAME is set, the add_peer logic > derives a local dummy cluster key based on the local cluster's configuration. > CLUSTER_KEY shouldn't be required when an ENDPOINT_CLASSNAME is specified, > because a custom endpoint might not need it. The dummy default logic is fine. > > But if an endpoint does require a remote cluster key, it shouldn't be > forbidden to provide one, especially since the Java API permits it, and even > the custom replication endpoint Java tests rely on this. (See > TestReplicationEndpoint#testCustomReplicationEndpoint) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[ https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15479069#comment-15479069 ] Hudson commented on HBASE-16576: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #1573 (See [https://builds.apache.org/job/HBase-Trunk_matrix/1573/]) HBASE-16576 Shell add_peer doesn't allow setting cluster_key for custom (apurtell: rev e1e06372004bd9c6694d5489ede4d0529512f699) * (edit) hbase-shell/src/main/ruby/shell/commands/add_peer.rb * (edit) hbase-shell/src/main/ruby/hbase/replication_admin.rb * (edit) hbase-shell/src/test/ruby/hbase/replication_admin_test.rb > Shell add_peer doesn't allow setting cluster_key for custom endpoints > - > > Key: HBASE-16576 > URL: https://issues.apache.org/jira/browse/HBASE-16576 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.0.0, 1.1.5, 0.98.22 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 2.0.0, 1.4.0, 0.98.23 > > Attachments: HBASE-16576-0.98.patch, HBASE-16576.patch, > HBASE-16576.v1.patch > > > The HBase shell allows a user to create a replication peer using the add_peer > method, which can take a peer id and a Ruby hash. It creates a > ReplicationPeerConfig and passes it through to the Java > ReplicationAdmin#addPeer. > The Ruby code makes an assumption that the Java API doesn't: that CLUSTER_KEY > and ENDPOINT_CLASSNAME are mutually exclusive. If both are specified, it > throws an error. If only ENDPOINT_CLASSNAME is set, the add_peer logic > derives a local dummy cluster key based on the local cluster's configuration. > CLUSTER_KEY shouldn't be required when an ENDPOINT_CLASSNAME is specified, > because a custom endpoint might not need it. The dummy default logic is fine. > > But if an endpoint does require a remote cluster key, it shouldn't be > forbidden to provide one, especially since the Java API permits it, and even > the custom replication endpoint Java tests rely on this. (See > TestReplicationEndpoint#testCustomReplicationEndpoint) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[ https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15478733#comment-15478733 ] Hudson commented on HBASE-16576: FAILURE: Integrated in Jenkins build HBase-1.4 #406 (See [https://builds.apache.org/job/HBase-1.4/406/]) HBASE-16576 Shell add_peer doesn't allow setting cluster_key for custom (apurtell: rev fe57fa4daa303f4d0612c7200a7a1145b336ff7c) * (edit) hbase-shell/src/main/ruby/shell/commands/add_peer.rb * (edit) hbase-shell/src/main/ruby/hbase/replication_admin.rb * (edit) hbase-shell/src/test/ruby/hbase/replication_admin_test.rb > Shell add_peer doesn't allow setting cluster_key for custom endpoints > - > > Key: HBASE-16576 > URL: https://issues.apache.org/jira/browse/HBASE-16576 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.0.0, 1.1.5, 0.98.22 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 2.0.0, 1.4.0, 0.98.23 > > Attachments: HBASE-16576-0.98.patch, HBASE-16576.patch, > HBASE-16576.v1.patch > > > The HBase shell allows a user to create a replication peer using the add_peer > method, which can take a peer id and a Ruby hash. It creates a > ReplicationPeerConfig and passes it through to the Java > ReplicationAdmin#addPeer. > The Ruby code makes an assumption that the Java API doesn't: that CLUSTER_KEY > and ENDPOINT_CLASSNAME are mutually exclusive. If both are specified, it > throws an error. If only ENDPOINT_CLASSNAME is set, the add_peer logic > derives a local dummy cluster key based on the local cluster's configuration. > CLUSTER_KEY shouldn't be required when an ENDPOINT_CLASSNAME is specified, > because a custom endpoint might not need it. The dummy default logic is fine. > > But if an endpoint does require a remote cluster key, it shouldn't be > forbidden to provide one, especially since the Java API permits it, and even > the custom replication endpoint Java tests rely on this. (See > TestReplicationEndpoint#testCustomReplicationEndpoint) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[ https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15478379#comment-15478379 ] Andrew Purtell commented on HBASE-16576: Pushed to master, branch-1, and 0.98 > Shell add_peer doesn't allow setting cluster_key for custom endpoints > - > > Key: HBASE-16576 > URL: https://issues.apache.org/jira/browse/HBASE-16576 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.0.0, 1.1.5, 0.98.22 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 2.0.0, 1.4.0, 0.98.23 > > Attachments: HBASE-16576-0.98.patch, HBASE-16576.patch, > HBASE-16576.v1.patch > > > The HBase shell allows a user to create a replication peer using the add_peer > method, which can take a peer id and a Ruby hash. It creates a > ReplicationPeerConfig and passes it through to the Java > ReplicationAdmin#addPeer. > The Ruby code makes an assumption that the Java API doesn't: that CLUSTER_KEY > and ENDPOINT_CLASSNAME are mutually exclusive. If both are specified, it > throws an error. If only ENDPOINT_CLASSNAME is set, the add_peer logic > derives a local dummy cluster key based on the local cluster's configuration. > CLUSTER_KEY shouldn't be required when an ENDPOINT_CLASSNAME is specified, > because a custom endpoint might not need it. The dummy default logic is fine. > > But if an endpoint does require a remote cluster key, it shouldn't be > forbidden to provide one, especially since the Java API permits it, and even > the custom replication endpoint Java tests rely on this. (See > TestReplicationEndpoint#testCustomReplicationEndpoint) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[
https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15478219#comment-15478219
]
Hadoop QA commented on HBASE-16576:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 19s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
0s {color} | {color:green} 0.98 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
24s {color} | {color:green} 0.98 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 9s
{color} | {color:green} 0.98 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 9s
{color} | {color:green} 0.98 passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m 8s
{color} | {color:red} The patch generated 10 new + 139 unchanged - 16 fixed =
149 total (was 155) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m 6s
{color} | {color:red} The patch generated 4 new + 155 unchanged - 8 fixed = 159
total (was 163) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
11m 57s {color} | {color:green} The patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 7s
{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 10s
{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 4m 33s {color}
| {color:red} hbase-shell in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
12s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 25m 12s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestShell |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:date2016-09-09 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12827823/HBASE-16576-0.98.patch
|
| JIRA Issue | HBASE-16576 |
| Optional Tests | asflicense javac javadoc unit rubocop ruby_lint |
| uname | Linux 00bdd1b11d79 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/patchprocess/precommit/personality/hbase.sh |
| git revision | 0.98 / 9317955 |
| Default Java | 1.7.0_111 |
| Multi-JDK versions | /usr/lib/jvm/java-8-oracle:1.8.0_101
/usr/lib/jvm/java-7-openjdk-amd64:1.7.0_111 |
| rubocop | v0.42.0 |
| rubocop |
https://builds.apache.org/job/PreCommit-HBASE-Build/3487/artifact/patchprocess/diff-patch-rubocop.txt
|
| ruby-lint | v2.3.0 |
| ruby-lint |
https://builds.apache.org/job/PreCommit-HBASE-Build/3487/artifact/patchprocess/diff-patch-ruby-lint.txt
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/3487/artifact/patchprocess/patch-unit-hbase-shell.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/3487/artifact/patchprocess/patch-unit-hbase-shell.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/3487/testReport/ |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/3487/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[ https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15478187#comment-15478187 ] Andrew Purtell commented on HBASE-16576: Thanks [~gjacoby]. bq. I had to locally deactivate the lone test in TaskMonitorTest that seemed to be a flapper in order to get TestShell to consistently pass Mind filing a JIRA with a fix version of 0.98.23 with details on that? Thanks. > Shell add_peer doesn't allow setting cluster_key for custom endpoints > - > > Key: HBASE-16576 > URL: https://issues.apache.org/jira/browse/HBASE-16576 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.0.0, 1.1.5, 0.98.22 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Attachments: HBASE-16576-0.98.patch, HBASE-16576.patch, > HBASE-16576.v1.patch > > > The HBase shell allows a user to create a replication peer using the add_peer > method, which can take a peer id and a Ruby hash. It creates a > ReplicationPeerConfig and passes it through to the Java > ReplicationAdmin#addPeer. > The Ruby code makes an assumption that the Java API doesn't: that CLUSTER_KEY > and ENDPOINT_CLASSNAME are mutually exclusive. If both are specified, it > throws an error. If only ENDPOINT_CLASSNAME is set, the add_peer logic > derives a local dummy cluster key based on the local cluster's configuration. > CLUSTER_KEY shouldn't be required when an ENDPOINT_CLASSNAME is specified, > because a custom endpoint might not need it. The dummy default logic is fine. > > But if an endpoint does require a remote cluster key, it shouldn't be > forbidden to provide one, especially since the Java API permits it, and even > the custom replication endpoint Java tests rely on this. (See > TestReplicationEndpoint#testCustomReplicationEndpoint) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[ https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15478159#comment-15478159 ] Geoffrey Jacoby commented on HBASE-16576: - I created an 0.98 patch. I had to locally deactivate the lone test in TaskMonitorTest that seemed to be a flapper in order to get TestShell to consistently pass. Also I see that HBASE-16600 was just filed where the replication admin tests appear to be flapping, but I didn't see that. > Shell add_peer doesn't allow setting cluster_key for custom endpoints > - > > Key: HBASE-16576 > URL: https://issues.apache.org/jira/browse/HBASE-16576 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.0.0, 1.1.5, 0.98.22 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Attachments: HBASE-16576-0.98.patch, HBASE-16576.patch, > HBASE-16576.v1.patch > > > The HBase shell allows a user to create a replication peer using the add_peer > method, which can take a peer id and a Ruby hash. It creates a > ReplicationPeerConfig and passes it through to the Java > ReplicationAdmin#addPeer. > The Ruby code makes an assumption that the Java API doesn't: that CLUSTER_KEY > and ENDPOINT_CLASSNAME are mutually exclusive. If both are specified, it > throws an error. If only ENDPOINT_CLASSNAME is set, the add_peer logic > derives a local dummy cluster key based on the local cluster's configuration. > CLUSTER_KEY shouldn't be required when an ENDPOINT_CLASSNAME is specified, > because a custom endpoint might not need it. The dummy default logic is fine. > > But if an endpoint does require a remote cluster key, it shouldn't be > forbidden to provide one, especially since the Java API permits it, and even > the custom replication endpoint Java tests rely on this. (See > TestReplicationEndpoint#testCustomReplicationEndpoint) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[ https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15475643#comment-15475643 ] Geoffrey Jacoby commented on HBASE-16576: - Thanks, I'll supply an 0.98 patch. > Shell add_peer doesn't allow setting cluster_key for custom endpoints > - > > Key: HBASE-16576 > URL: https://issues.apache.org/jira/browse/HBASE-16576 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.0.0, 1.1.5, 0.98.22 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Attachments: HBASE-16576.patch, HBASE-16576.v1.patch > > > The HBase shell allows a user to create a replication peer using the add_peer > method, which can take a peer id and a Ruby hash. It creates a > ReplicationPeerConfig and passes it through to the Java > ReplicationAdmin#addPeer. > The Ruby code makes an assumption that the Java API doesn't: that CLUSTER_KEY > and ENDPOINT_CLASSNAME are mutually exclusive. If both are specified, it > throws an error. If only ENDPOINT_CLASSNAME is set, the add_peer logic > derives a local dummy cluster key based on the local cluster's configuration. > CLUSTER_KEY shouldn't be required when an ENDPOINT_CLASSNAME is specified, > because a custom endpoint might not need it. The dummy default logic is fine. > > But if an endpoint does require a remote cluster key, it shouldn't be > forbidden to provide one, especially since the Java API permits it, and even > the custom replication endpoint Java tests rely on this. (See > TestReplicationEndpoint#testCustomReplicationEndpoint) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[ https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1547#comment-1547 ] Andrew Purtell commented on HBASE-16576: TestShell passes when this is applied to master and branch-1 (with a small fixup). Branch-1 patch also applies to 0.98 but the test fails there. Shall we stop at master and branch-1, or would you like to supply an 0.98 patch [~gjacoby] ? > Shell add_peer doesn't allow setting cluster_key for custom endpoints > - > > Key: HBASE-16576 > URL: https://issues.apache.org/jira/browse/HBASE-16576 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.0.0, 1.1.5, 0.98.22 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Attachments: HBASE-16576.patch, HBASE-16576.v1.patch > > > The HBase shell allows a user to create a replication peer using the add_peer > method, which can take a peer id and a Ruby hash. It creates a > ReplicationPeerConfig and passes it through to the Java > ReplicationAdmin#addPeer. > The Ruby code makes an assumption that the Java API doesn't: that CLUSTER_KEY > and ENDPOINT_CLASSNAME are mutually exclusive. If both are specified, it > throws an error. If only ENDPOINT_CLASSNAME is set, the add_peer logic > derives a local dummy cluster key based on the local cluster's configuration. > CLUSTER_KEY shouldn't be required when an ENDPOINT_CLASSNAME is specified, > because a custom endpoint might not need it. The dummy default logic is fine. > > But if an endpoint does require a remote cluster key, it shouldn't be > forbidden to provide one, especially since the Java API permits it, and even > the custom replication endpoint Java tests rely on this. (See > TestReplicationEndpoint#testCustomReplicationEndpoint) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[ https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15475433#comment-15475433 ] Enis Soztutar commented on HBASE-16576: --- Makes sense. Here is the code that does this: ReplicationPeerZKImpl.getPeerConf(). We split the clusterKey into 3 pieces, and manually set the zk quorum and root znode in the cloned configuration for the peer. Then we do a compound configuration from the base one + ReplicationPeerConfig.getConfiguration() entries. This was designed to be the way to pass custom configuration (like hbase-site.xml properties) per peer. For example, you can have different rpc timeouts, retries etc per peer if you manually set it in the peer config. > Shell add_peer doesn't allow setting cluster_key for custom endpoints > - > > Key: HBASE-16576 > URL: https://issues.apache.org/jira/browse/HBASE-16576 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.0.0, 1.1.5, 0.98.22 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Attachments: HBASE-16576.patch, HBASE-16576.v1.patch > > > The HBase shell allows a user to create a replication peer using the add_peer > method, which can take a peer id and a Ruby hash. It creates a > ReplicationPeerConfig and passes it through to the Java > ReplicationAdmin#addPeer. > The Ruby code makes an assumption that the Java API doesn't: that CLUSTER_KEY > and ENDPOINT_CLASSNAME are mutually exclusive. If both are specified, it > throws an error. If only ENDPOINT_CLASSNAME is set, the add_peer logic > derives a local dummy cluster key based on the local cluster's configuration. > CLUSTER_KEY shouldn't be required when an ENDPOINT_CLASSNAME is specified, > because a custom endpoint might not need it. The dummy default logic is fine. > > But if an endpoint does require a remote cluster key, it shouldn't be > forbidden to provide one, especially since the Java API permits it, and even > the custom replication endpoint Java tests rely on this. (See > TestReplicationEndpoint#testCustomReplicationEndpoint) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[ https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15475144#comment-15475144 ] Andrew Purtell commented on HBASE-16576: I will commit this later today after poking around with it for a bit > Shell add_peer doesn't allow setting cluster_key for custom endpoints > - > > Key: HBASE-16576 > URL: https://issues.apache.org/jira/browse/HBASE-16576 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.0.0, 1.1.5, 0.98.22 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Attachments: HBASE-16576.patch, HBASE-16576.v1.patch > > > The HBase shell allows a user to create a replication peer using the add_peer > method, which can take a peer id and a Ruby hash. It creates a > ReplicationPeerConfig and passes it through to the Java > ReplicationAdmin#addPeer. > The Ruby code makes an assumption that the Java API doesn't: that CLUSTER_KEY > and ENDPOINT_CLASSNAME are mutually exclusive. If both are specified, it > throws an error. If only ENDPOINT_CLASSNAME is set, the add_peer logic > derives a local dummy cluster key based on the local cluster's configuration. > CLUSTER_KEY shouldn't be required when an ENDPOINT_CLASSNAME is specified, > because a custom endpoint might not need it. The dummy default logic is fine. > > But if an endpoint does require a remote cluster key, it shouldn't be > forbidden to provide one, especially since the Java API permits it, and even > the custom replication endpoint Java tests rely on this. (See > TestReplicationEndpoint#testCustomReplicationEndpoint) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[ https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15475141#comment-15475141 ] Andrew Purtell commented on HBASE-16576: +1 bq. Others are left unaddressed – for example, it's complaining about the cyclomatic complexity being too high in replication_admin, The blame for this is not the proposed changes > Shell add_peer doesn't allow setting cluster_key for custom endpoints > - > > Key: HBASE-16576 > URL: https://issues.apache.org/jira/browse/HBASE-16576 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.0.0, 1.1.5, 0.98.22 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Attachments: HBASE-16576.patch, HBASE-16576.v1.patch > > > The HBase shell allows a user to create a replication peer using the add_peer > method, which can take a peer id and a Ruby hash. It creates a > ReplicationPeerConfig and passes it through to the Java > ReplicationAdmin#addPeer. > The Ruby code makes an assumption that the Java API doesn't: that CLUSTER_KEY > and ENDPOINT_CLASSNAME are mutually exclusive. If both are specified, it > throws an error. If only ENDPOINT_CLASSNAME is set, the add_peer logic > derives a local dummy cluster key based on the local cluster's configuration. > CLUSTER_KEY shouldn't be required when an ENDPOINT_CLASSNAME is specified, > because a custom endpoint might not need it. The dummy default logic is fine. > > But if an endpoint does require a remote cluster key, it shouldn't be > forbidden to provide one, especially since the Java API permits it, and even > the custom replication endpoint Java tests rely on this. (See > TestReplicationEndpoint#testCustomReplicationEndpoint) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[
https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15472188#comment-15472188
]
Hadoop QA commented on HBASE-16576:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 14s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
9s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 7s
{color} | {color:green} master passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 9s
{color} | {color:green} master passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m 7s
{color} | {color:red} The patch generated 9 new + 156 unchanged - 16 fixed =
165 total (was 172) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m 6s
{color} | {color:red} The patch generated 3 new + 155 unchanged - 8 fixed = 158
total (was 163) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 48s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 7s
{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 10s
{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 6m 35s
{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 39m 50s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:date2016-09-07 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12827464/HBASE-16576.v1.patch |
| JIRA Issue | HBASE-16576 |
| Optional Tests | asflicense javac javadoc unit rubocop ruby_lint |
| uname | Linux f02133fc9c57 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / e9cfbfd |
| Default Java | 1.7.0_111 |
| Multi-JDK versions | /usr/lib/jvm/java-8-oracle:1.8.0_101
/usr/lib/jvm/java-7-openjdk-amd64:1.7.0_111 |
| rubocop | v0.42.0 |
| rubocop |
https://builds.apache.org/job/PreCommit-HBASE-Build/3444/artifact/patchprocess/diff-patch-rubocop.txt
|
| ruby-lint | v2.3.0 |
| ruby-lint |
https://builds.apache.org/job/PreCommit-HBASE-Build/3444/artifact/patchprocess/diff-patch-ruby-lint.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/3444/testReport/ |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/3444/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Shell add_peer doesn't allow setting cluster_key for custom endpoints
> -
>
> Key: HBASE-16576
> URL:
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[ https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15472114#comment-15472114 ] Geoffrey Jacoby commented on HBASE-16576: - Interesting. I'd be curious to know how to set an endpoint via individual config parameters -- just have the three properties use the same key in ReplicationPeerConfig's Configuration as in an HBase configuration object? That's an undocumented usage, I think. Regardless of whether CLUSTER_KEY or the individual parameters are the best way for setting the target of an endpoint, whether CLUSTER_KEY's legal shouldn't matter whether or not an operator's using a built-in or custom endpoint. I still think the patch is worthwhile even if there happens to be a workaround. > Shell add_peer doesn't allow setting cluster_key for custom endpoints > - > > Key: HBASE-16576 > URL: https://issues.apache.org/jira/browse/HBASE-16576 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.0.0, 1.1.5, 0.98.22 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Attachments: HBASE-16576.patch, HBASE-16576.v1.patch > > > The HBase shell allows a user to create a replication peer using the add_peer > method, which can take a peer id and a Ruby hash. It creates a > ReplicationPeerConfig and passes it through to the Java > ReplicationAdmin#addPeer. > The Ruby code makes an assumption that the Java API doesn't: that CLUSTER_KEY > and ENDPOINT_CLASSNAME are mutually exclusive. If both are specified, it > throws an error. If only ENDPOINT_CLASSNAME is set, the add_peer logic > derives a local dummy cluster key based on the local cluster's configuration. > CLUSTER_KEY shouldn't be required when an ENDPOINT_CLASSNAME is specified, > because a custom endpoint might not need it. The dummy default logic is fine. > > But if an endpoint does require a remote cluster key, it shouldn't be > forbidden to provide one, especially since the Java API permits it, and even > the custom replication endpoint Java tests rely on this. (See > TestReplicationEndpoint#testCustomReplicationEndpoint) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[ https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15472113#comment-15472113 ] Geoffrey Jacoby commented on HBASE-16576: - Interesting. I'd be curious to know how to set an endpoint via individual config parameters -- just have the three properties use the same key in ReplicationPeerConfig's Configuration as in an HBase configuration object? That's an undocumented usage, I think. Regardless of whether CLUSTER_KEY or the individual parameters are the best way for setting the target of an endpoint, whether CLUSTER_KEY's legal shouldn't matter whether or not an operator's using a built-in or custom endpoint. I still think the patch is worthwhile even if there happens to be a workaround. > Shell add_peer doesn't allow setting cluster_key for custom endpoints > - > > Key: HBASE-16576 > URL: https://issues.apache.org/jira/browse/HBASE-16576 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 2.0.0, 1.1.5, 0.98.22 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Attachments: HBASE-16576.patch, HBASE-16576.v1.patch > > > The HBase shell allows a user to create a replication peer using the add_peer > method, which can take a peer id and a Ruby hash. It creates a > ReplicationPeerConfig and passes it through to the Java > ReplicationAdmin#addPeer. > The Ruby code makes an assumption that the Java API doesn't: that CLUSTER_KEY > and ENDPOINT_CLASSNAME are mutually exclusive. If both are specified, it > throws an error. If only ENDPOINT_CLASSNAME is set, the add_peer logic > derives a local dummy cluster key based on the local cluster's configuration. > CLUSTER_KEY shouldn't be required when an ENDPOINT_CLASSNAME is specified, > because a custom endpoint might not need it. The dummy default logic is fine. > > But if an endpoint does require a remote cluster key, it shouldn't be > forbidden to provide one, especially since the Java API permits it, and even > the custom replication endpoint Java tests rely on this. (See > TestReplicationEndpoint#testCustomReplicationEndpoint) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[
https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15472006#comment-15472006
]
Hadoop QA commented on HBASE-16576:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 12s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
1s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 7s
{color} | {color:green} master passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 9s
{color} | {color:green} master passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m 7s
{color} | {color:red} The patch generated 15 new + 158 unchanged - 14 fixed =
173 total (was 172) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m 6s
{color} | {color:red} The patch generated 4 new + 155 unchanged - 8 fixed = 159
total (was 163) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
26m 55s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 7s
{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 9s
{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 6m 25s
{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
7s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 38m 32s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:date2016-09-07 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12827454/HBASE-16576.patch |
| JIRA Issue | HBASE-16576 |
| Optional Tests | asflicense javac javadoc unit rubocop ruby_lint |
| uname | Linux 1f2368f0ea82 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28
20:42:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / e9cfbfd |
| Default Java | 1.7.0_111 |
| Multi-JDK versions | /usr/lib/jvm/java-8-oracle:1.8.0_101
/usr/lib/jvm/java-7-openjdk-amd64:1.7.0_111 |
| rubocop | v0.42.0 |
| rubocop |
https://builds.apache.org/job/PreCommit-HBASE-Build/3443/artifact/patchprocess/diff-patch-rubocop.txt
|
| ruby-lint | v2.3.0 |
| ruby-lint |
https://builds.apache.org/job/PreCommit-HBASE-Build/3443/artifact/patchprocess/diff-patch-ruby-lint.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/3443/testReport/ |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/3443/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Shell add_peer doesn't allow setting cluster_key for custom endpoints
> -
>
> Key: HBASE-16576
> URL:
[jira] [Commented] (HBASE-16576) Shell add_peer doesn't allow setting cluster_key for custom endpoints
[
https://issues.apache.org/jira/browse/HBASE-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471955#comment-15471955
]
Enis Soztutar commented on HBASE-16576:
---
clusterKey is kind of a hack to pass multiple key,value pairs which are
specifically needed for hbase connections. It is a concatenation of
"hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent",
which should not be needed at all even if the replication endpoint is
{{HBaseInterClusterReplicationEndpoint}}. Each of these individual config
params can be specified separately now in the configuration for
ReplicationPeerConfig object.
> Shell add_peer doesn't allow setting cluster_key for custom endpoints
> -
>
> Key: HBASE-16576
> URL: https://issues.apache.org/jira/browse/HBASE-16576
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 2.0.0, 1.1.5, 0.98.22
>Reporter: Geoffrey Jacoby
>Assignee: Geoffrey Jacoby
> Attachments: HBASE-16576.patch
>
>
> The HBase shell allows a user to create a replication peer using the add_peer
> method, which can take a peer id and a Ruby hash. It creates a
> ReplicationPeerConfig and passes it through to the Java
> ReplicationAdmin#addPeer.
> The Ruby code makes an assumption that the Java API doesn't: that CLUSTER_KEY
> and ENDPOINT_CLASSNAME are mutually exclusive. If both are specified, it
> throws an error. If only ENDPOINT_CLASSNAME is set, the add_peer logic
> derives a local dummy cluster key based on the local cluster's configuration.
> CLUSTER_KEY shouldn't be required when an ENDPOINT_CLASSNAME is specified,
> because a custom endpoint might not need it. The dummy default logic is fine.
>
> But if an endpoint does require a remote cluster key, it shouldn't be
> forbidden to provide one, especially since the Java API permits it, and even
> the custom replication endpoint Java tests rely on this. (See
> TestReplicationEndpoint#testCustomReplicationEndpoint)
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
