[jira] [Created] (HBASE-20779) Server version is not right when enable TABLES_ON_MASTER
Guanghao Zhang created HBASE-20779: -- Summary: Server version is not right when enable TABLES_ON_MASTER Key: HBASE-20779 URL: https://issues.apache.org/jira/browse/HBASE-20779 Project: HBase Issue Type: Bug Reporter: Guanghao Zhang When eable TABLES_ON_MASTER, master will be a region server to carry regions. So it will report to itself, too. And we get server version from rpc call. But master report to itself will skip rpc call. Then ServerManager will record a wrong version 0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-18622) Mitigate API compatibility concerns between branch-1 and branch-2
[ https://issues.apache.org/jira/browse/HBASE-18622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-18622. --- Resolution: Fixed Fix Version/s: 2.0.2 Resolving. Subtasks done. We published a report when we released 2.0.0 (though its probably hard to digest -- could have done better). > Mitigate API compatibility concerns between branch-1 and branch-2 > - > > Key: HBASE-18622 > URL: https://issues.apache.org/jira/browse/HBASE-18622 > Project: HBase > Issue Type: Bug > Components: API >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 3.0.0, 2.1.0, 2.0.2 > > Attachments: report.1.2_2.0.html.gz > > > This project is to do what [~apurtell] did in the issue "HBASE-18431 Mitigate > compatibility concerns between branch-1.3 and branch-1.4" only do it between > branch-1 and branch-2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20778) Make it so WALPE runs on DFS
stack created HBASE-20778: - Summary: Make it so WALPE runs on DFS Key: HBASE-20778 URL: https://issues.apache.org/jira/browse/HBASE-20778 Project: HBase Issue Type: Bug Components: test Reporter: stack Assignee: stack Fix For: 2.0.2 WALPE is broke for running on DFS. The old issue is the cause HBASE-9908 (making stuff work on windows) though it went in a long time ago. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20777) TestAsyncTableBatch is flakey
Duo Zhang created HBASE-20777: - Summary: TestAsyncTableBatch is flakey Key: HBASE-20777 URL: https://issues.apache.org/jira/browse/HBASE-20777 Project: HBase Issue Type: Bug Reporter: Duo Zhang Attachments: org.apache.hadoop.hbase.client.TestAsyncTableBatch-output.txt The log is very strange, we keep sending request to a dead RS, and the result is not connection refused, but rpc timeout, and later it becomes CallQueueTooBig... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
CVE-2018-8025 on Apache HBase
CVE-2018-8025 describes an issue in Apache HBase that affects the optional "Thrift 1" API server when running over HTTP. There is a race-condition which could lead to authenticated sessions being incorrectly applied to users, e.g. one authenticated user would be considered a different user or an unauthenticated user would be treated as an authenticated user. https://issues.apache.org/jira/browse/HBASE-20664 implements a fix for this issue, and this fix is contained in the following releases of Apache HBase: * 1.2.6.1 * 1.3.2.1 * 1.4.5 * 2.0.1 This vulnerability affects all 1.x and 2.x release lines (except 1.0.0). - The Apache HBase PMC
[jira] [Created] (HBASE-20776) Update branch-2 version to 2.2.0-SNAPSHOT
Duo Zhang created HBASE-20776: - Summary: Update branch-2 version to 2.2.0-SNAPSHOT Key: HBASE-20776 URL: https://issues.apache.org/jira/browse/HBASE-20776 Project: HBase Issue Type: Sub-task Components: build Reporter: Duo Zhang Assignee: Duo Zhang -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-20747) Cut branch-2.1
[ https://issues.apache.org/jira/browse/HBASE-20747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-20747. --- Resolution: Fixed > Cut branch-2.1 > -- > > Key: HBASE-20747 > URL: https://issues.apache.org/jira/browse/HBASE-20747 > Project: HBase > Issue Type: Sub-task > Components: build >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: On the 2.1.0 and 3.0.0 release
Pushed branch-2.1 at this commit. commit a86141b6252a433ff62f5c1979d7523031da0bf2 Author: zhangduo Date: Thu Jun 21 10:14:57 2018 +0800 HBASE-20752 Make sure the regions are truly reopened after ReopenTableRegionsProcedure 2018-06-22 15:10 GMT+08:00 张铎(Duo Zhang) : > Hold on committing to branch-2. Will cut branch-2.1 soon. > > 2018-06-19 22:05 GMT+08:00 张铎(Duo Zhang) : > >> Moved a bunch of issues out of 2.1.0. You can add it back if you think >> this is important for 2.1.0 release but we need to be quick. Will cut >> branch-2.1 after finish the related issues around SCP and MRP, maybe end of >> this week. >> >> Thanks. >> >> 2018-06-13 15:00 GMT+08:00 张铎(Duo Zhang) : >> >>> I set HBASE-20708 as a blocker for 2.1.0 release, and I also think we >>> need to address HBASE-20706. Will keep working on it. >>> >>> 2018-06-13 14:11 GMT+08:00 Stack : >>> On Sun, Jun 3, 2018 at 8:54 PM 张铎(Duo Zhang) wrote: > What;s your plan sir? Branch branch-2.1 from branch-2.0? > > Dang. Its time to push out a new release -- it is > 6 weeks since 2.0.0 -- but I'll just call it 2.0.1. It has 70+ fixes in it which is an awful lot for a patch release (It is our first release after a major so we might allow ourselves some slack) but they are just bug fixes and some perf improvements; it doesn't feel substantial enough (yet) to claim 2.1.0. I can see 2.0.2, 2.0.3 coming at about same interval but again just bug fixes and perf: no new features. I relinquish any claim on 2.1.0. S > 2018-06-04 11:50 GMT+08:00 Stack : > > > On Sun, Jun 3, 2018 at 5:36 PM, 张铎(Duo Zhang) < palomino...@gmail.com> > > wrote: > > > > > Will cut the 2.1 branch tomorrow if no objections. The unfinished > > features > > > will be disabled by default or purged from branch-2.1 and target to 2.2 > > > release. > > > > > > > > I was thinking that the next release off branch-2.0 could be 2.1.0. It > has > > 70+ commits including a big boost in perf. It feels more like a minor > > release than it does a point release. > > > > Branch 3.0.0 rather than 2.1.0 Duo? > > > > S > > > > > > > > > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) : > > > > > > > Plan to cut branch-2.1 at the end of May. Will consider the status of > > the > > > > new features at that time to determine what will be released with > 2.1.x > > > > release line. > > > > > > > > 2018-05-08 10:16 GMT+08:00 Josh Elser : > > > > > > > >> Big big big +1 > > > >> > > > >> (Came in to say just this but you beat me to it :D) > > > >> > > > >> > > > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote: > > > >> > > > >>> Let's do big features in 3.0.0 only. > > > >>> > > > >>> Ideally there will no big new features for a minor release, so that > > we > > > >>> can > > > >>> move the stable pointer to newer minor versions quickly and retire > > the > > > >>> old > > > >>> branches. It will be a nightmare if we have lots of active minor > > > release > > > >>> lines... > > > >>> > > > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang >>> >: > > > >>> > > > >>> Why 2.1 doesn't contatin synchronous replication? This can be a > > > experiment > > > feature in 2.1? > > > > > > 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) < palomino...@gmail.com>: > > > > > > 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai < chia7...@apache.org>: > > > > > > > > As I volunteered to be the release manager for the 2.1 release > line > > > >>> > > > >> so > > > > > > > let > > > >> > > > >>> me bring this up. > > > >>> > > > >> +1 to Duo be RM of 2.1 release. > > > >> > > > >> disabled from 2.0.0 release, for example, serial replication, > and > > in > > > >>> > > > >> memory compaction > > > >> IIRC, in memory compaction is enabled in 2.0 and the default > > policy > > > is > > > >> BASIC. (please correct me if I misunderstand something.) > > > >> > > > >> We disabled it by default in the end due to some performance > > > issues... > > > > > > > > > > > >> For the 2.1 release line, I would like to define it as the > 'real' > > > 2.x > > > >>> > > > >> Seems the release date between 2.0 and 2.1 will be very close. > Is > > it > > > >> related to our new release plan? (IIRC, Andrew had suggested > some > > > >> great > > > >> release plan based
Re: On the 2.1.0 and 3.0.0 release
Hold on committing to branch-2. Will cut branch-2.1 soon. 2018-06-19 22:05 GMT+08:00 张铎(Duo Zhang) : > Moved a bunch of issues out of 2.1.0. You can add it back if you think > this is important for 2.1.0 release but we need to be quick. Will cut > branch-2.1 after finish the related issues around SCP and MRP, maybe end of > this week. > > Thanks. > > 2018-06-13 15:00 GMT+08:00 张铎(Duo Zhang) : > >> I set HBASE-20708 as a blocker for 2.1.0 release, and I also think we >> need to address HBASE-20706. Will keep working on it. >> >> 2018-06-13 14:11 GMT+08:00 Stack : >> >>> On Sun, Jun 3, 2018 at 8:54 PM 张铎(Duo Zhang) >>> wrote: >>> >>> > What;s your plan sir? Branch branch-2.1 from branch-2.0? >>> > >>> > >>> Dang. Its time to push out a new release -- it is > 6 weeks since 2.0.0 >>> -- >>> but I'll just call it 2.0.1. It has 70+ fixes in it which is an awful lot >>> for a patch release (It is our first release after a major so we might >>> allow ourselves some slack) but they are just bug fixes and some perf >>> improvements; it doesn't feel substantial enough (yet) to claim 2.1.0. I >>> can see 2.0.2, 2.0.3 coming at about same interval but again just bug >>> fixes >>> and perf: no new features. I relinquish any claim on 2.1.0. >>> >>> S >>> >>> >>> >>> >>> >>> > 2018-06-04 11:50 GMT+08:00 Stack : >>> > >>> > > On Sun, Jun 3, 2018 at 5:36 PM, 张铎(Duo Zhang) >> > >>> > > wrote: >>> > > >>> > > > Will cut the 2.1 branch tomorrow if no objections. The unfinished >>> > > features >>> > > > will be disabled by default or purged from branch-2.1 and target >>> to 2.2 >>> > > > release. >>> > > > >>> > > > >>> > > I was thinking that the next release off branch-2.0 could be 2.1.0. >>> It >>> > has >>> > > 70+ commits including a big boost in perf. It feels more like a minor >>> > > release than it does a point release. >>> > > >>> > > Branch 3.0.0 rather than 2.1.0 Duo? >>> > > >>> > > S >>> > > >>> > > >>> > > >>> > > > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) : >>> > > > >>> > > > > Plan to cut branch-2.1 at the end of May. Will consider the >>> status of >>> > > the >>> > > > > new features at that time to determine what will be released with >>> > 2.1.x >>> > > > > release line. >>> > > > > >>> > > > > 2018-05-08 10:16 GMT+08:00 Josh Elser : >>> > > > > >>> > > > >> Big big big +1 >>> > > > >> >>> > > > >> (Came in to say just this but you beat me to it :D) >>> > > > >> >>> > > > >> >>> > > > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote: >>> > > > >> >>> > > > >>> Let's do big features in 3.0.0 only. >>> > > > >>> >>> > > > >>> Ideally there will no big new features for a minor release, so >>> that >>> > > we >>> > > > >>> can >>> > > > >>> move the stable pointer to newer minor versions quickly and >>> retire >>> > > the >>> > > > >>> old >>> > > > >>> branches. It will be a nightmare if we have lots of active >>> minor >>> > > > release >>> > > > >>> lines... >>> > > > >>> >>> > > > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang >> >: >>> > > > >>> >>> > > > >>> Why 2.1 doesn't contatin synchronous replication? This can be a >>> > > > experiment >>> > > > feature in 2.1? >>> > > > >>> > > > 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) < >>> palomino...@gmail.com>: >>> > > > >>> > > > 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai < >>> chia7...@apache.org>: >>> > > > > >>> > > > > As I volunteered to be the release manager for the 2.1 >>> release >>> > line >>> > > > >>> >>> > > > >> so >>> > > > >>> > > > > let >>> > > > >> >>> > > > >>> me bring this up. >>> > > > >>> >>> > > > >> +1 to Duo be RM of 2.1 release. >>> > > > >> >>> > > > >> disabled from 2.0.0 release, for example, serial >>> replication, >>> > and >>> > > in >>> > > > >>> >>> > > > >> memory compaction >>> > > > >> IIRC, in memory compaction is enabled in 2.0 and the default >>> > > policy >>> > > > is >>> > > > >> BASIC. (please correct me if I misunderstand something.) >>> > > > >> >>> > > > >> We disabled it by default in the end due to some performance >>> > > > issues... >>> > > > > >>> > > > > >>> > > > >> For the 2.1 release line, I would like to define it as the >>> > 'real' >>> > > > 2.x >>> > > > >>> >>> > > > >> Seems the release date between 2.0 and 2.1 will be very >>> close. >>> > Is >>> > > it >>> > > > >> related to our new release plan? (IIRC, Andrew had suggested >>> > some >>> > > > >> great >>> > > > >> release plan based time. But I fail to find the thread...) >>> > > > >> >>> > > > >> And for the 3.0.0 release, I think the new features should >>> be >>> > > > decided >>> > > > >>> >>> > > > >> ASAP. >>> > > > >> >>> > > > >>> We need to avoid the same thing happens again, i.e, >>> spending 2 >>> > > > years >>> > > > >>> >>> > > > >> to >>> > > > >>> > > > > release a major version... >>> > > > >>> >>> > > > >> agreed! >>> > > > >> >>> > > > >
