> And on backporting to branch-2, I think this is all to Nick as he is the release manager.
I'd like to take it into branch-2 as soon as we can. We've done a major round of stabilization of branch-2, but that concluded before the winter break. Now that we've had a handful of major features land, I'm anticipating another round of stabilization in the coming weeks. The reasons I can think of to NOT back-port it for 2.3 are the following: 1. Does not conform with our minor release compatibility "promises". 2. Introduces significant changes to the assignment manager. 3. Introduces known complications with JDK11. Unfortunately I've still not had time to review the meat of the patch. I expect there to be changes to the AM, but I hope those changes are isolated and not systemic. If there are significant reviewer concerns AND someone is up for managing the overhead, what do you think about maintaining a back port branch that is regularly rebased onto branch-2? We can start our stabilization efforts on that feature branch. If it's looking good, the merge will be trivial. If it's problematic, the feature can receive further attention and we've not destabilized the pending release. This is begging another unaddressed question -- are we going to continue branching for the 2.x minor release lines? Will we release directly from branch-2, as we have started with branch-1? Thanks, Nick On Mon, Mar 2, 2020 at 8:59 AM Andrew Purtell <[email protected]> wrote: > +1 > > Also, +1 to putting this in 2.4. Will give us one of hopefully several > reasons to keep moving forward. No need to delay the 2.3 release train. > > I'd like to try to pick up the backport of this at my employer as part of > adopting 2.4 in some way, for what it's worth. I think maybe 2.4 for us for > this reason (rsgroups improvements!!) but also some minor but also minor > release requiring changes to coprocessor APIs. Will discuss the latter > point with you soon on a JIRA issue. > > On Mon, Mar 2, 2020 at 6:12 AM Sean Busbey <[email protected]> wrote: > > > Personally, I'd rather see the branch-2 backport wait for 2.4. the 2.3 > > release has been "close" for a while now and 2.2 came out in June > > 2019. > > > > On Mon, Mar 2, 2020 at 1:16 AM 张铎(Duo Zhang) <[email protected]> > > wrote: > > > > > > Thanks stack, so finally we have 3 binding +1s now. > > > > > > Let merge the branch back. And on backporting to branch-2, I think this > > is > > > all to Nick as he is the release manager. > > > > > > Thanks! > > > > > > Stack <[email protected]> 于2020年3月2日周一 下午1:40写道： > > > > > > > I'm +1 on backport. Will keep an eye on it. > > > > S > > > > > > > > On Sat, Feb 22, 2020 at 5:32 AM Duo Zhang <[email protected]> > wrote: > > > > > > > > > The issue aims to make rs group the first class citizen in HBase, > > where > > > > the > > > > > feature can be enabled through a simple flag, not a complicated > > > > > coprocessor, and also we can manage it through the Admin interface, > > while > > > > > in the old time the only public way is to through the shell > command, > > as > > > > the > > > > > coprocessor client is marked as IA.Private. > > > > > > > > > > This is a simple design doc > > > > > > > > > > <goog_2028452043> > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/1SuodZ_uDQQQVJyryRxqp033cgz2aQPJmjIREbbbmB3c/edit?usp=sharing > > > > > > > > > > The PR for all the changes > > > > > > > > > > https://github.com/apache/hbase/pull/1165 > > > > > > > > > > And let me copy the release note here > > > > > > > > > > Moved rs group feature into core. Use this flag to enable or > disable > > it. > > > > > > > > > > The coprocessor > org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint > > is > > > > > deprected, but for compatible, if you want the pre 3.0.0 hbase > > > > client/shell > > > > > to communicate with the new hbase cluster, you still need to add > this > > > > > coprocessor to master. And if this coprocessor is specified, the > > above > > > > flag > > > > > will be set to true automatically to enable rs group feature. > > > > > > > > > > These methods are added to the Admin/AsyncAdmin interface for > > managing rs > > > > > groups. See the javadoc of these methods for more details. > > > > > > > > > > void addRSGroup(String groupName) throws IOException; > > > > > RSGroupInfo getRSGroup(String groupName) throws IOException; > > > > > RSGroupInfo getRSGroup(Address hostPort) throws IOException; > > > > > RSGroupInfo getRSGroup(TableName tableName) throws IOException; > > > > > List<RSGroupInfo> listRSGroups() throws IOException; > > > > > List<TableName> listTablesInRSGroup(String groupName) throws > > > > IOException; > > > > > Pair<List<String>, List<TableName>> > > > > > getConfiguredNamespacesAndTablesInRSGroup(String groupName) throws > > > > > IOException; > > > > > void removeRSGroup(String groupName) throws IOException; > > > > > void removeServersFromRSGroup(Set<Address> servers) throws > > IOException; > > > > > void moveServersToRSGroup(Set<Address> servers, String > targetGroup) > > > > > throws IOException; > > > > > void setRSGroup(Set<TableName> tables, String groupName) throws > > > > > IOException; > > > > > boolean balanceRSGroup(String groupName) throws IOException; > > > > > > > > > > The shell commands for rs group are not changed. > > > > > > > > > > The main difference on the implementation is that, now the rs group > > for a > > > > > table is stored in TableDescriptor, instead of in RSGroupInfo, so > the > > > > > getTables method of RSGroupInfo has been deprecated. And if you use > > the > > > > > above Admin methods to get the RSGroupInfo, its getTables method > will > > > > > always return empty. Of course the behavior for the old > > > > > RSGroupAdminEndpoint is not changed, we will fill the tables field > > of the > > > > > RSGroupInfo before returning, to make it compatible with old hbase > > > > > client/shell. > > > > > > > > > > When upgrading, the migration between the RSGroupInfo and > > TableDescriptor > > > > > will be done automatically. It will take sometime, but it is fine > to > > > > > restart master in the middle, the migration will continue after > > restart. > > > > > > > > > > The vote will open for at least 72 hours. > > > > > > > > > > Please vote > > > > > > > > > > [+1] Agree > > > > > [-1] Disagree > > > > > > > > > > Thanks. > > > > > > > > > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > - A23, Crosstalk >
