[jira] [Resolved] (HBASE-24596) Document general framework to execute remote procedure on RegionServer
[ https://issues.apache.org/jira/browse/HBASE-24596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Stack resolved HBASE-24596. --- Resolution: Duplicate Resolving as duplicate of HBASE-24596 (I thought I'd filed one already...) > Document general framework to execute remote procedure on RegionServer > -- > > Key: HBASE-24596 > URL: https://issues.apache.org/jira/browse/HBASE-24596 > Project: HBase > Issue Type: Sub-task > Components: documentation >Reporter: Michael Stack >Priority: Major > > Document -- probably best in javadoc -- the system added by HBASE-19216 > 'Implement a general framework to execute remote procedure on RS ' for having > procedures run tasks on remote regionservers. The system evolved a good while > ago in HBASE-19216 to manage replication peers. It was then adopted by the > new procedure-based distributed WAL splitting feature with some worry that > the latter didn't use the framework properly (so far, all looks good). > This issue is about vetting the distributed WAL splitters usage and doc'ing > the framework as I go. This framework is useful. Others will want to exploit > it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-24762) Purge protobuf java 2.5.0 dependency
[ https://issues.apache.org/jira/browse/HBASE-24762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-24762. --- Hadoop Flags: Reviewed Resolution: Fixed Merged to master. On branch-2, we still have hbase-protocol which depends on protobuf 2.5.0 so whether to apply this patch is not very important. > Purge protobuf java 2.5.0 dependency > > > Key: HBASE-24762 > URL: https://issues.apache.org/jira/browse/HBASE-24762 > Project: HBase > Issue Type: Sub-task > Components: dependencies, Protobufs >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0-alpha-1 > > > On master branch, we have removed the hbase-protocol module so in general, we > do not need to depend on protobuf 2.5.0 directl. Especially for hadoop 3.3.0, > hadoop will not depend on 2.5.0 any more, we should make sure hbase do not > introduce protobuf 2.5.0 too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-24768) Clear service kerberos ticket in case of SASL failures from server side
Sandeep Guggilam created HBASE-24768: Summary: Clear service kerberos ticket in case of SASL failures from server side Key: HBASE-24768 URL: https://issues.apache.org/jira/browse/HBASE-24768 Project: HBase Issue Type: Bug Reporter: Sandeep Guggilam Assignee: Sandeep Guggilam We setup a SASL connection using different mechanisms like Digest, Kerberos from master to RS for various activities like region assignment etc. In case of SASL connect failures, we try to dispose of the SaslRpcClient and try to relogin from the keytab on the client side. However the relogin from keytab method doesn't clear off the service ticket cached in memory unless TGT is about to expire within a timeframe. This actually causes an issue where there is a keytab refresh that happens because of expiry on the RS server and throws a SASL connect error when Master reaches out to the RS server with the cached service ticket that no longer works with the new refreshed keytab. We might need to clear off the service ticket cached as there could be a credential refresh on the RS server side when handling connect failures -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-24743) Reject to add a peer which replicate to itself earlier
[
https://issues.apache.org/jira/browse/HBASE-24743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang resolved HBASE-24743.
Resolution: Fixed
All ut passed. Pushed to branch-2 and master.
> Reject to add a peer which replicate to itself earlier
> --
>
> Key: HBASE-24743
> URL: https://issues.apache.org/jira/browse/HBASE-24743
> Project: HBase
> Issue Type: Improvement
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.4.0
>
>
> Now there are one check in ReplicationSource#initialize method
> {code:java}
> // In rare case, zookeeper setting may be messed up. That leads to the
> incorrect
> // peerClusterId value, which is the same as the source clusterId
> if (clusterId.equals(peerClusterId) &&
> !replicationEndpoint.canReplicateToSameCluster()) {
> this.terminate("ClusterId " + clusterId + " is replicating to itself:
> peerClusterId "
> + peerClusterId + " which is not allowed by ReplicationEndpoint:"
> + replicationEndpoint.getClass().getName(), null, false);
> this.manager.removeSource(this);
> return;
> }
> {code}
> This check should move to AddPeerProcedure's precheck.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (HBASE-24767) Change default to false for HBASE-15519 per-user metrics
Michael Stack created HBASE-24767: - Summary: Change default to false for HBASE-15519 per-user metrics Key: HBASE-24767 URL: https://issues.apache.org/jira/browse/HBASE-24767 Project: HBase Issue Type: Bug Components: metrics Affects Versions: 2.3.0 Reporter: Michael Stack Assignee: Michael Stack Fix For: 3.0.0-alpha-1, 2.3.1, 2.4.0 HBASE-15519 added a nice feature to show per-user metrics. It needs a bit of work still – see base of HBASE-15519 for notes but in particular, it can spin up lots of threads, more than makes sense – but currently it is enabled by default. Here we disable it by setting default for hbase.regionserver.user.metrics.enabled to false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-24766) Document Remote Procedure Execution
Michael Stack created HBASE-24766: - Summary: Document Remote Procedure Execution Key: HBASE-24766 URL: https://issues.apache.org/jira/browse/HBASE-24766 Project: HBase Issue Type: Bug Components: documentation Reporter: Michael Stack The doc in ServerRemoteProcedure, the main class is good. I said I'd give it a tuneup now we've a few impls of this feature. I want to doc in the code rather than in refguide since it devs who would use it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-24763) Update 2.1 documentation to 2.1.9 and remove direct link from main page
[ https://issues.apache.org/jira/browse/HBASE-24763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi resolved HBASE-24763. --- Fix Version/s: 3.0.0-alpha-1 Resolution: Fixed Pushed 2.1.9 docs to hbase-site repository and removed "2.1 Documentation" menu item from website. Thanks for the review [~busbey] and [~janh]! > Update 2.1 documentation to 2.1.9 and remove direct link from main page > --- > > Key: HBASE-24763 > URL: https://issues.apache.org/jira/browse/HBASE-24763 > Project: HBase > Issue Type: Task > Components: documentation, website >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Major > Fix For: 3.0.0-alpha-1 > > > For the 2.1 release the available documentation points to 2.1.5. Since the > release has reached EOL with 2.1.9 the documentation on the website should > reflect this and a direct link to 2.1 should be removed. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-24765) Dynamic master discovery
Bharath Vissapragada created HBASE-24765:
Summary: Dynamic master discovery
Key: HBASE-24765
URL: https://issues.apache.org/jira/browse/HBASE-24765
Project: HBase
Issue Type: Sub-task
Components: Client
Affects Versions: 2.3.0, 3.0.0-alpha-1
Reporter: Bharath Vissapragada
Assignee: Bharath Vissapragada
[~stack]'s idea in the design doc for splittable-meta.
We can keep a live list of masters to query by fetching the list of available
masters from any of the available masters configured in the seed list. User
configured list of masters ("hbase.masters") would be used as a seed list.
The endpoints are refreshed every 5mins or if any of the registry RPCs hit an
error (which ever happens first).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (HBASE-24764) Add support of enabling default peer configs via hbase-site.xml for all default replication peers.
Ankit Jain created HBASE-24764: -- Summary: Add support of enabling default peer configs via hbase-site.xml for all default replication peers. Key: HBASE-24764 URL: https://issues.apache.org/jira/browse/HBASE-24764 Project: HBase Issue Type: Improvement Reporter: Ankit Jain Assignee: Ankit Jain Currently, if a user needs to apply some common peer configs to all the default replication peers, the only way is to execute update_peer_config via CLI which requires manual intervention and can be tedious in case of large deployment fleet. As part of this JIRA, we plan to add the support to have default replication peer configs as part of hbase-site.xml like hbase.replication.peer.default.config="k1=v1;k2=v2.." which can be just applied by a rolling restart. Example below: hbase.replication.peer.default.configs hbase.replication.source.custom.walentryfilters=x,y,z;hbase.rpc.protection=abc;hbase.xxx.custom_property=123 This will be empty by default, but one can override to have default configs in place. The final peer configuration would be a merge of this default config + whatever users override during the peer creation/update (if any). Related Jira: https://issues.apache.org/jira/browse/HBASE-17543. HBASE-17543 added the support to add the WALEntryFilters to default endpoint via peer configuration. By this new Jira we are extending the support to update peer configs via hbase-site.xml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-24209) [Hadoop3.3] Add Hadoop-3.3.0-SNAPSHOT to hadoopcheck in our yetus personality
[ https://issues.apache.org/jira/browse/HBASE-24209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei-Chiu Chuang resolved HBASE-24209. - Resolution: Won't Fix > [Hadoop3.3] Add Hadoop-3.3.0-SNAPSHOT to hadoopcheck in our yetus personality > - > > Key: HBASE-24209 > URL: https://issues.apache.org/jira/browse/HBASE-24209 > Project: HBase > Issue Type: Task > Components: build >Reporter: Nick Dimiduk >Assignee: Wei-Chiu Chuang >Priority: Major > > Since HBASE-23833 we're paying attention to our builds on Hadoop trunk, > currently 3.3.0-SNAPSHOT. Let's add this version to the version lists in > hadoopcheck so our CI will let us know when things break, at least > compile-time anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-24763) Update 2.1 documentation to 2.1.9 and remove direct link from main page
Peter Somogyi created HBASE-24763: - Summary: Update 2.1 documentation to 2.1.9 and remove direct link from main page Key: HBASE-24763 URL: https://issues.apache.org/jira/browse/HBASE-24763 Project: HBase Issue Type: Task Components: documentation, website Reporter: Peter Somogyi Assignee: Peter Somogyi For the 2.1 release the available documentation points to 2.1.5. Since the release has reached EOL with 2.1.9 the documentation on the website should reflect this and a direct link to 2.1 should be removed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-24675) On Master restart all servers are assigned to default rsgroup.
[
https://issues.apache.org/jira/browse/HBASE-24675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani resolved HBASE-24675.
--
Resolution: Fixed
> On Master restart all servers are assigned to default rsgroup.
> --
>
> Key: HBASE-24675
> URL: https://issues.apache.org/jira/browse/HBASE-24675
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Affects Versions: 2.2.3
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.3.1, 1.7.0, 2.4.0, 2.2.7
>
>
> Steps to reproduce:
> # Install a HBase cluster with three RS(rs1,rs2 and rs3) and one Master
> # Create two rsgroups r1 and r2 and move rs1 to r1 and rs2 to r2
> {code:java}
> add_rsgroup 'r1';add_rsgroup 'r2';move_servers_rsgroup
> 'r1',['host1:16020'];move_servers_rsgroup 'r2',['host2:16020']
> {code}
> # Restart Master
> # Run list_rsgroups for hbase shell, all region servers are assigned to
> default regroup.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (HBASE-24696) Include JVM information on Web UI under "Software Attributes"
[ https://issues.apache.org/jira/browse/HBASE-24696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viraj Jasani resolved HBASE-24696. -- Fix Version/s: 2.2.7 2.1.10 Resolution: Fixed > Include JVM information on Web UI under "Software Attributes" > - > > Key: HBASE-24696 > URL: https://issues.apache.org/jira/browse/HBASE-24696 > Project: HBase > Issue Type: Improvement > Components: UI >Reporter: Nick Dimiduk >Assignee: Mingliang Liu >Priority: Minor > Fix For: 3.0.0-alpha-1, 2.3.1, 1.7.0, 2.4.0, 2.1.10, 2.2.7 > > Attachments: Screen Shot 2020-07-17 at 10.55.56 PM.png > > > It's a small thing, but seems like an omission. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-24761) Support hadoop 3.3.0
[ https://issues.apache.org/jira/browse/HBASE-24761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-24761. --- Resolution: Duplicate > Support hadoop 3.3.0 > > > Key: HBASE-24761 > URL: https://issues.apache.org/jira/browse/HBASE-24761 > Project: HBase > Issue Type: Umbrella > Components: hadoop3 >Reporter: Duo Zhang >Priority: Major > > A good thing is that, finally hadoop upgraded protobuf and also shaded the > protobuf it uses. > Let's try to support it, and also we can purge our own dependencies on > protobuf 2.5.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-24762) Purge protobuf java 2.5.0 dependency
Duo Zhang created HBASE-24762: - Summary: Purge protobuf java 2.5.0 dependency Key: HBASE-24762 URL: https://issues.apache.org/jira/browse/HBASE-24762 Project: HBase Issue Type: Sub-task Components: dependencies, Protobufs Reporter: Duo Zhang Assignee: Duo Zhang Fix For: 3.0.0-alpha-1 On master branch, we have removed the hbase-protocol module so in general, we do not need to depend on protobuf 2.5.0 directl. Especially for hadoop 3.3.0, hadoop will not depend on 2.5.0 any more, we should make sure hbase do not introduce protobuf 2.5.0 too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-24761) Support hadoop 3.3.0
Duo Zhang created HBASE-24761: - Summary: Support hadoop 3.3.0 Key: HBASE-24761 URL: https://issues.apache.org/jira/browse/HBASE-24761 Project: HBase Issue Type: Umbrella Components: hadoop3 Reporter: Duo Zhang A good thing is that, finally hadoop upgraded protobuf and also shaded the protobuf it uses. Let's try to support it, and also we can purge our own dependencies on protobuf 2.5.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-24760) Allow system tables fallback to any rs groups
Sun Xin created HBASE-24760: --- Summary: Allow system tables fallback to any rs groups Key: HBASE-24760 URL: https://issues.apache.org/jira/browse/HBASE-24760 Project: HBase Issue Type: New Feature Components: rsgroup Affects Versions: 3.0.0-alpha-1 Reporter: Sun Xin Assignee: Sun Xin Fix For: 3.0.0-alpha-1 In HBASE-22738 we allow tables fallback to specific rs groups, If there is no online servers in the table's rsgroup. But for system tables, It is necessary to allow system tables fallback to any rsgroup in order to keey available at all times. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] The first HBase 2.2.6 release candidate (RC0) is available
+1 (binding) Signatures & checksums: ok Changes, release notes: ok Compatibility report: ok Rat check: ok Built from source: ok Unit test: ok Shell basic commands: ok LTT 1M rows: ok On Mon, Jul 20, 2020 at 5:24 AM Guanghao Zhang wrote: > Please vote on this release candidate (RC) for Apache HBase 2.2.6. > > The VOTE will remain open for at least 72 hours. > > [ ] +1 Release this package as Apache HBase 2.2.6 > [ ] -1 Do not release this package because ... > > The tag to be voted on is 2.2.6RC0. The release files, including > signatures, digests, etc. can be found at: > https://dist.apache.org/repos/dist/dev/hbase/2.2.6RC0/ > > Maven artifacts are available in a staging repository at: > https://repository.apache.org/content/repositories/orgapachehbase-1401 > > Signatures used for HBase RCs can be found in this file: > https://dist.apache.org/repos/dist/release/hbase/KEYS > > The list of bug fixes going into 2.2.6 can be found in included > CHANGES.md and RELEASENOTES.md available here: > https://dist.apache.org/repos/dist/dev/hbase/2.2.6RC0/CHANGES.md > https://dist.apache.org/repos/dist/dev/hbase/2.2.6RC0/RELEASENOTES.md > > A detailed source and binary compatibility report for this release is > available at: > > https://dist.apache.org/repos/dist/dev/hbase/2.2.6RC0/api_compare_2.2.6RC0_to_2.2.5.html > > To learn more about Apache HBase, please see http://hbase.apache.org/ > > Thanks, > Guanghao Zhang >
[jira] [Created] (HBASE-24759) Persisting configuration of default rsgroup
Sun Xin created HBASE-24759: --- Summary: Persisting configuration of default rsgroup Key: HBASE-24759 URL: https://issues.apache.org/jira/browse/HBASE-24759 Project: HBase Issue Type: New Feature Components: rsgroup Affects Versions: 3.0.0-alpha-1 Reporter: Sun Xin Assignee: Sun Xin Fix For: 3.0.0-alpha-1 In the current scenario, we didn't store the default rsgroup information. But after HBASE-24431 , we have added a config map, which need to be persisted to avoid lossing config of default rsgroup. -- This message was sent by Atlassian Jira (v8.3.4#803005)
