Re: [DISCUSS] Move the stable pointer to 2.3.x and EOM for branch-2.2?
Good idea +1. On Tue, Dec 15, 2020 at 9:43 PM Huaxiang Sun wrote: > +1 (non-binding). > > On Tue, Dec 15, 2020 at 9:14 PM Viraj Jasani wrote: > > > I believe last time when we discussed this, we were considering stability > > of migration from MasterProcWAL to MasterProc directory (WAL to region > > based procedure store) during rolling upgrade from 2.2.x to 2.3.x. I hope > > we are good with this. > > > > > > On Wed, 16 Dec 2020 at 10:27 AM, Viraj Jasani > wrote: > > > > > +1 > > > > > > On Wed, 16 Dec 2020 at 6:38 AM, Guanghao Zhang > > wrote: > > > > > >> Hi folks! > > >> > > >> Now we cut new branch-2.4 and the 2.4.0 will be released. We can EOM > for > > >> branch-2.2 to reduce the maintenance work. Meanwhile, I thought > > branch-2.3 > > >> is more stable than branch-2.2 because you guys take great test work > > when > > >> release 2.3.0. And for branch-2.2, the 2.2.7 may be the last of the > > 2.2.x > > >> releases. > > >> > > >> Any thoughts? > > >> > > > > > >
Re: [DISCUSS] Move the stable pointer to 2.3.x and EOM for branch-2.2?
+1 (non-binding). On Tue, Dec 15, 2020 at 9:14 PM Viraj Jasani wrote: > I believe last time when we discussed this, we were considering stability > of migration from MasterProcWAL to MasterProc directory (WAL to region > based procedure store) during rolling upgrade from 2.2.x to 2.3.x. I hope > we are good with this. > > > On Wed, 16 Dec 2020 at 10:27 AM, Viraj Jasani wrote: > > > +1 > > > > On Wed, 16 Dec 2020 at 6:38 AM, Guanghao Zhang > wrote: > > > >> Hi folks! > >> > >> Now we cut new branch-2.4 and the 2.4.0 will be released. We can EOM for > >> branch-2.2 to reduce the maintenance work. Meanwhile, I thought > branch-2.3 > >> is more stable than branch-2.2 because you guys take great test work > when > >> release 2.3.0. And for branch-2.2, the 2.2.7 may be the last of the > 2.2.x > >> releases. > >> > >> Any thoughts? > >> > > >
Re: [DISCUSS] Move the stable pointer to 2.3.x and EOM for branch-2.2?
I believe last time when we discussed this, we were considering stability of migration from MasterProcWAL to MasterProc directory (WAL to region based procedure store) during rolling upgrade from 2.2.x to 2.3.x. I hope we are good with this. On Wed, 16 Dec 2020 at 10:27 AM, Viraj Jasani wrote: > +1 > > On Wed, 16 Dec 2020 at 6:38 AM, Guanghao Zhang wrote: > >> Hi folks! >> >> Now we cut new branch-2.4 and the 2.4.0 will be released. We can EOM for >> branch-2.2 to reduce the maintenance work. Meanwhile, I thought branch-2.3 >> is more stable than branch-2.2 because you guys take great test work when >> release 2.3.0. And for branch-2.2, the 2.2.7 may be the last of the 2.2.x >> releases. >> >> Any thoughts? >> >
[jira] [Created] (HBASE-25400) [Flakey Tests] branch-2 TestRegionMoveAndAbandon
Michael Stack created HBASE-25400: - Summary: [Flakey Tests] branch-2 TestRegionMoveAndAbandon Key: HBASE-25400 URL: https://issues.apache.org/jira/browse/HBASE-25400 Project: HBase Issue Type: Task Reporter: Michael Stack Looks to be same as 'HBASE-25389 [Flakey Tests] branch-2 TestMetaShutdownHandler (#2773)' One-liner seems to shut this flakey down (I'm running unit tests locally.. it has failed a few times on me). -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Move the stable pointer to 2.3.x and EOM for branch-2.2?
+1 (non-binding) On Tue, Dec 15, 2020 at 10:23 PM Nick Dimiduk wrote: > Good plan, +1 ! > > On Tue, Dec 15, 2020 at 17:08 Guanghao Zhang wrote: > > > Hi folks! > > > > Now we cut new branch-2.4 and the 2.4.0 will be released. We can EOM for > > branch-2.2 to reduce the maintenance work. Meanwhile, I thought > branch-2.3 > > is more stable than branch-2.2 because you guys take great test work when > > release 2.3.0. And for branch-2.2, the 2.2.7 may be the last of the 2.2.x > > releases. > > > > Any thoughts? > > >
Re: Time for 2.3.4
Thank you Huaxiang ! On Tue, Dec 15, 2020 at 15:09 Huaxiang Sun wrote: > Continue this topic. I volunteered to be RM for 2.3.4. I plan to warm up > this release process starting from tomorrow. Per Nick said 2 weeks ago, if > there are any patch-level bug fixes you want to include in 2.3.4, please > wrap them up in couple of days. > > Thanks, > Huaxiang > > On Fri, Dec 4, 2020 at 8:38 AM Nick Dimiduk wrote: > > > Heya, > > > > It's past time to start the 2.3.4 release process. I plan to let the > 2.4.0 > > release run its course before adding this release to the PMC burden. I > will > > change my mind if the 2.4.0 release ends up dragging out for several > weeks > > for some reason. In the meantime, please wrap up any patch-level bug > fixes > > you might be sitting on. > > > > Thanks, > > Nick > > >
[jira] [Resolved] (HBASE-25365) The log in move_servers_rsgroup is incorrect
[
https://issues.apache.org/jira/browse/HBASE-25365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Stack resolved HBASE-25365.
---
Fix Version/s: 3.0.0-alpha-1
Hadoop Flags: Reviewed
Resolution: Fixed
Merged to master. Thanks for the patch [~DeanZ]. Tried backport but conflicts.
If you want a backport, put up a PR? Thank you.
> The log in move_servers_rsgroup is incorrect
>
>
> Key: HBASE-25365
> URL: https://issues.apache.org/jira/browse/HBASE-25365
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.0
>Reporter: Baiqiang Zhao
>Assignee: Baiqiang Zhao
>Priority: Minor
> Fix For: 3.0.0-alpha-1
>
>
> Assuming that server1 belongs to the default group, execute the command:
>
> {code:java}
> move_servers_rsgroup 'test',['server1:16020']
> {code}
> We can see log:
>
> {code:java}
> Moving 10 region(s) to group test, current retry=0
> ..
> All regions from server(s) [server1,16020,1607067542905] moved to target
> group test.
> {code}
> The target group should be the source group in log: test -> default.
>
> https://github.com/apache/hbase/blob/7d0a687e5798a2f4ca3190b409169f7e17a75b34/hbase-server/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfoManagerImpl.java#L1027
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSS] Move the stable pointer to 2.3.x and EOM for branch-2.2?
Good plan, +1 ! On Tue, Dec 15, 2020 at 17:08 Guanghao Zhang wrote: > Hi folks! > > Now we cut new branch-2.4 and the 2.4.0 will be released. We can EOM for > branch-2.2 to reduce the maintenance work. Meanwhile, I thought branch-2.3 > is more stable than branch-2.2 because you guys take great test work when > release 2.3.0. And for branch-2.2, the 2.2.7 may be the last of the 2.2.x > releases. > > Any thoughts? >
Re: [DISCUSS] Move the stable pointer to 2.3.x and EOM for branch-2.2?
+1 > On Dec 15, 2020, at 5:41 PM, Stack wrote: > > +1 > >> On Tue, Dec 15, 2020 at 5:08 PM Guanghao Zhang wrote: >> >> Hi folks! >> >> Now we cut new branch-2.4 and the 2.4.0 will be released. We can EOM for >> branch-2.2 to reduce the maintenance work. Meanwhile, I thought branch-2.3 >> is more stable than branch-2.2 because you guys take great test work when >> release 2.3.0. And for branch-2.2, the 2.2.7 may be the last of the 2.2.x >> releases. >> >> Any thoughts? >>
Re: [DISCUSS] Move the stable pointer to 2.3.x and EOM for branch-2.2?
+1 On Tue, Dec 15, 2020 at 5:08 PM Guanghao Zhang wrote: > Hi folks! > > Now we cut new branch-2.4 and the 2.4.0 will be released. We can EOM for > branch-2.2 to reduce the maintenance work. Meanwhile, I thought branch-2.3 > is more stable than branch-2.2 because you guys take great test work when > release 2.3.0. And for branch-2.2, the 2.2.7 may be the last of the 2.2.x > releases. > > Any thoughts? >
Re: [DISCUSS] Move the stable pointer to 2.3.x and EOM for branch-2.2?
+1 Guanghao Zhang 于2020年12月16日周三 上午9:08写道： > Hi folks! > > Now we cut new branch-2.4 and the 2.4.0 will be released. We can EOM for > branch-2.2 to reduce the maintenance work. Meanwhile, I thought branch-2.3 > is more stable than branch-2.2 because you guys take great test work when > release 2.3.0. And for branch-2.2, the 2.2.7 may be the last of the 2.2.x > releases. > > Any thoughts? >
[DISCUSS] Move the stable pointer to 2.3.x and EOM for branch-2.2?
Hi folks! Now we cut new branch-2.4 and the 2.4.0 will be released. We can EOM for branch-2.2 to reduce the maintenance work. Meanwhile, I thought branch-2.3 is more stable than branch-2.2 because you guys take great test work when release 2.3.0. And for branch-2.2, the 2.2.7 may be the last of the 2.2.x releases. Any thoughts?
Re: Time for 2.3.4
Continue this topic. I volunteered to be RM for 2.3.4. I plan to warm up this release process starting from tomorrow. Per Nick said 2 weeks ago, if there are any patch-level bug fixes you want to include in 2.3.4, please wrap them up in couple of days. Thanks, Huaxiang On Fri, Dec 4, 2020 at 8:38 AM Nick Dimiduk wrote: > Heya, > > It's past time to start the 2.3.4 release process. I plan to let the 2.4.0 > release run its course before adding this release to the PMC burden. I will > change my mind if the 2.4.0 release ends up dragging out for several weeks > for some reason. In the meantime, please wrap up any patch-level bug fixes > you might be sitting on. > > Thanks, > Nick >
Re: [RESULT] [VOTE] First release candidate for HBase 2.4.0 (RC1) is available
On Tue, Dec 15, 2020 at 11:26 AM Andrew Purtell wrote: > With six (6) binding +1 votes including my own, and one (1) nonbinding +1 > vote, and no 0 or -1 votes, this vote passes. > > Thanks to all who voted on the release candidate. > Thank you for taking this on, Andrew! On Thu, Dec 3, 2020 at 4:04 PM Andrew Purtell wrote: > > > Please vote on this Apache hbase release candidate, hbase-2.4.0RC1 > > > > The VOTE will remain open for at least 72 hours. > > > > [ ] +1 Release this package as Apache hbase 2.4.0 > > [ ] -1 Do not release this package because ... > > > > The tag to be voted on is 2.4.0RC1: > > > > https://github.com/apache/hbase/tree/2.4.0RC1 > > > > The release files, including signatures, digests, as well as CHANGES.md > > and RELEASENOTES.md included in this RC can be found at: > > > > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/ > > > > Customarily Maven artifacts would be available in a staging repository. > > Unfortunately I was forced to terminate the Maven deploy step after > > the upload ran for more than four hours and my build equipment > > needed to be relocated, with loss of network connectivity. This RC has > > been delayed long enough. A temporary Maven repository is not a > > requirement for a vote. I will retry Maven deploy tomorrow. I can > > promise the artifacts for this RC will be staged in Apache Nexus and > > ready for release well ahead of the earliest possible time this vote > > can complete. > > > > Artifacts were signed with the apurt...@apache.org key which can be > found > > in: > > > > https://dist.apache.org/repos/dist/release/hbase/KEYS > > > > The API compatibility report for this RC can be found at: > > > > > > > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html > > > > The changes are mostly added methods, which conform to the compatibility > > guidelines for a new minor release. There is one change to the public > > Region interface that alters the return type of a method. This is > > equivalent to a removal then addition and can be a binary compatibility > > problem. However to your RM's eye the change looks intentional and is > > part of an API improvement project, and a compatibility method is not > > possible here because Java doesn't consider return type when deciding if > > one method signature duplicates another. > > > > To learn more about Apache HBase, please see > > > > http://hbase.apache.org/ > > > > Thanks, > > Your HBase Release Manager > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk >
[RESULT] [VOTE] First release candidate for HBase 2.4.0 (RC1) is available
With six (6) binding +1 votes including my own, and one (1) nonbinding +1 vote, and no 0 or -1 votes, this vote passes. Thanks to all who voted on the release candidate. On Thu, Dec 3, 2020 at 4:04 PM Andrew Purtell wrote: > Please vote on this Apache hbase release candidate, hbase-2.4.0RC1 > > The VOTE will remain open for at least 72 hours. > > [ ] +1 Release this package as Apache hbase 2.4.0 > [ ] -1 Do not release this package because ... > > The tag to be voted on is 2.4.0RC1: > > https://github.com/apache/hbase/tree/2.4.0RC1 > > The release files, including signatures, digests, as well as CHANGES.md > and RELEASENOTES.md included in this RC can be found at: > > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/ > > Customarily Maven artifacts would be available in a staging repository. > Unfortunately I was forced to terminate the Maven deploy step after > the upload ran for more than four hours and my build equipment > needed to be relocated, with loss of network connectivity. This RC has > been delayed long enough. A temporary Maven repository is not a > requirement for a vote. I will retry Maven deploy tomorrow. I can > promise the artifacts for this RC will be staged in Apache Nexus and > ready for release well ahead of the earliest possible time this vote > can complete. > > Artifacts were signed with the apurt...@apache.org key which can be found > in: > > https://dist.apache.org/repos/dist/release/hbase/KEYS > > The API compatibility report for this RC can be found at: > > > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html > > The changes are mostly added methods, which conform to the compatibility > guidelines for a new minor release. There is one change to the public > Region interface that alters the return type of a method. This is > equivalent to a removal then addition and can be a binary compatibility > problem. However to your RM's eye the change looks intentional and is > part of an API improvement project, and a compatibility method is not > possible here because Java doesn't consider return type when deciding if > one method signature duplicates another. > > To learn more about Apache HBase, please see > > http://hbase.apache.org/ > > Thanks, > Your HBase Release Manager > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
[jira] [Resolved] (HBASE-25389) [Flakey Tests] branch-2 TestMetaShutdownHandler
[
https://issues.apache.org/jira/browse/HBASE-25389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Stack resolved HBASE-25389.
---
Fix Version/s: 2.4.1
2.5.0
3.0.0-alpha-1
Hadoop Flags: Reviewed
Assignee: Michael Stack
Resolution: Fixed
Merged to branch-2.4+. Thanks for the review [~bharathv]
> [Flakey Tests] branch-2 TestMetaShutdownHandler
> ---
>
> Key: HBASE-25389
> URL: https://issues.apache.org/jira/browse/HBASE-25389
> Project: HBase
> Issue Type: Task
> Components: flakies
>Reporter: Michael Stack
>Assignee: Michael Stack
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.1
>
>
> I see this in local runs fail regularly. We kill the server hosting meta and
> then check it came up in a new location after waiting on recovery. In the
> test, when it fails, the assert on new location fails because we have not
> waited for the CRASH to happen. Here is excerpt from log:
> {code}
> 2020-12-11 13:20:27,298 INFO [Listener at localhost/62149]
> master.TestMetaShutdownHandler(111): Deleted the znode for the RegionServer
> hosting hbase:meta; waiting on SSH
> ...
> 2020-12-11 13:20:27,310 INFO [Listener at localhost/62149]
> master.TestMetaShutdownHandler(122): Past wait on RIT
> ...
> 2020-12-11 13:20:27,351 DEBUG [RegionServerTracker-0]
> procedure2.ProcedureExecutor(1048): Stored pid=9,
> state=RUNNABLE:SERVER_CRASH_START; ServerCrashProcedure
> stack.XXX.example.com,62201,1607721618377, splitWal=true, meta=true
> {code}
> The first line is where we remove the ephemeral node for the regionserver
> carrying hbase:meta. The second line is supposed to log AFTER SCP is done (it
> calls it SSH in this old test above). Notice how the 3rd line, after the 2nd,
> is first mention of SCP being queued.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
