Over the weekend an issue[1] was submitted for Backup & Restore. I think it's potentially bad enough that it should be a blocker for this release. I already have a solution for the problem, so it shouldn't delay us much. I'm working on turning it into a PR now.
[1] https://issues.apache.org/jira/browse/HBASE-28456 On Sat, Mar 23, 2024 at 5:27 PM Bryan Beaudreault <bbeaudrea...@apache.org> wrote: > The INFRA ticket has been resolved, and I confirmed that I can now commit > the tarballs. > > Unfortunately, I realized that I used the wrong gpg key, so I need to > create a new RC. I'll kick that off tomorrow morning. > > On Fri, Mar 22, 2024 at 3:27 PM Bryan Beaudreault <bbeaudrea...@apache.org> > wrote: > >> Unfortunately, it still failed. This time it actually failed >> on hbase-2.6.0-hadoop3-client-bin.tar.gz, which is only 344MB. I tried it a >> few times and it swaps between that one and hbase-2.6.0-hadoop3-bin.tar.gz >> so maybe it's non-deterministically ordered. >> >> I wonder if a limit was just recently introduced. I'm still waiting on a >> response to my INFRA-25634 ticket. >> >> On Fri, Mar 22, 2024 at 12:59 PM Andrew Purtell <apurt...@apache.org> >> wrote: >> >>> > If something needs to be removed, I propose the full fat ( >>> > *hbase-shaded-client*) shaded client JAR. >>> > That is never returned by the hbase command AFAIK, and is also the >>> largest >>> > in size. >>> >>> Sounds good, if removing examples is insufficient, the limit cannot be >>> increased, and some other step need be taken. >>> >>> >>> On Thu, Mar 21, 2024 at 10:40 PM Istvan Toth <st...@cloudera.com.invalid >>> > >>> wrote: >>> >>> > The *hbase classpath* and *hbase mapredcp* command outputs do include >>> the >>> > respective *hbase-shaded-client-byo-hadoop* and >>> *hbase-shaded-mapreduce* >>> > jars. >>> > >>> > At least the 'hbase mapredcp' jars are used by both Spark and Hive >>> > integration, and expected to be available on the node filesystem. >>> > We also plan to switch the Phoenix connectors to that. >>> > >>> > Having those two jars in a separate assembly would require further >>> > configuration when installing HBase to tell it >>> > where to find them, so that the classpath commands can include them. >>> > >>> > If something needs to be removed, I propose the full fat ( >>> > *hbase-shaded-client*) shaded client JAR. >>> > That is never returned by the hbase command AFAIK, and is also the >>> largest >>> > in size. >>> > (I plan to remove that one from the upcoming Hadoop-less assembly as >>> well) >>> > >>> > Istvan >>> > >>> > On Fri, Mar 22, 2024 at 4:55 AM 张铎(Duo Zhang) <palomino...@gmail.com> >>> > wrote: >>> > >>> > > Tested locally, after removing hbase-example from tarball, the >>> hadoop3 >>> > > tarball is about 351MB. >>> > > >>> > > So you could try to include this commit to publish again, to see if >>> this >>> > > helps. >>> > > >>> > > Thanks. >>> > > >>> > > 张铎(Duo Zhang) <palomino...@gmail.com> 于2024年3月22日周五 09:18写道： >>> > > > >>> > > > If we exclude hbase-example from the binaries, will it be smaller >>> > enough >>> > > to fit? >>> > > > >>> > > > We already commit the changes to master I believe. Let me see if we >>> > > > can cherry-pick them and commit to branch-2.6 as well. >>> > > > >>> > > > Thanks. >>> > > > >>> > > > Bryan Beaudreault <bbeaudrea...@apache.org> 于2024年3月22日周五 07:35写道： >>> > > > > >>> > > > > Thanks, I filed >>> > > > > https://issues.apache.org/jira/browse/INFRA-25634 >>> > > > > >>> > > > > On Thu, Mar 21, 2024 at 5:46 PM Andrew Purtell < >>> apurt...@apache.org> >>> > > wrote: >>> > > > > >>> > > > > > The hadoop3 bin tarball for 2.5.8 is 352.8MB. Perhaps we have >>> just >>> > > barely >>> > > > > > and recently crossed a threshold. File an INFRA JIRA and ask >>> about >>> > > it. >>> > > > > > Perhaps some limit can be increased, or maybe they will ask us >>> to >>> > > live >>> > > > > > within it. >>> > > > > > >>> > > > > > Related, looking at the 2.5.8 hadoop3 bin tarball, the >>> majority of >>> > > the bulk >>> > > > > > is ./lib/shaded-clients/ . The shaded clients are certainly >>> useful >>> > > but >>> > > > > > probably are not the most popular options when taking a >>> dependency >>> > on >>> > > > > > HBase. Perhaps we can package these separately. We could >>> exclude >>> > > them from >>> > > > > > the convenience tarballs as they will still be available from >>> the >>> > > Apache >>> > > > > > Maven repository. >>> > > > > > >>> > > > > > On Thu, Mar 21, 2024 at 2:33 PM Bryan Beaudreault < >>> > > bbeaudrea...@apache.org >>> > > > > > > >>> > > > > > wrote: >>> > > > > > >>> > > > > > > I got most of the way through, but failed during >>> publish-dist: >>> > > > > > > >>> > > > > > > Transmitting file data ..svn: E175002: Commit failed (details >>> > > follow): >>> > > > > > > svn: E175002: PUT request on >>> > > > > > > >>> > > > > > > >>> > > > > > >>> > > >>> > >>> '/repos/dist/!svn/txr/68050-1le9/dev/hbase/2.6.0RC0/hbase-2.6.0-hadoop3-bin.tar.gz' >>> > > > > > > failed >>> > > > > > > >>> > > > > > > Running manually, it looks to be a Request Entity Too Large. >>> The >>> > > file in >>> > > > > > > question is 356MB. Anyone have any experience with this? >>> > > > > > > >>> > > > > > > On Thu, Mar 21, 2024 at 2:19 AM 张铎(Duo Zhang) < >>> > > palomino...@gmail.com> >>> > > > > > > wrote: >>> > > > > > > >>> > > > > > > > HBASE-28444 has been resolved. >>> > > > > > > > >>> > > > > > > > Please go ahead to cut 2.6.0RC0, really a long journey :) >>> > > > > > > > >>> > > > > > > > 张铎(Duo Zhang) <palomino...@gmail.com> 于2024年3月20日周三 >>> 14:29写道： >>> > > > > > > > > >>> > > > > > > > > There is a security issue for zookeeper, but simply >>> upgrading >>> > > > > > > > > zookeeper will break a test. >>> > > > > > > > > >>> > > > > > > > > Pelase see HBASE-28444 for more details. >>> > > > > > > > > >>> > > > > > > > > I think we should get this in before cutting the RC. >>> > > > > > > > > >>> > > > > > > > > Thanks. >>> > > > > > > > > >>> > > > > > > > > Bryan Beaudreault <bbeaudrea...@apache.org> >>> 于2024年3月19日周二 >>> > > 23:51写道： >>> > > > > > > > > > >>> > > > > > > > > > I've finished auditing fixVersions and run ITBLL for an >>> > > extended >>> > > > > > > > period of >>> > > > > > > > > > time in a real cluster. I'm not aware of any open >>> blockers. >>> > > So >>> > > > > > > > tomorrow I'm >>> > > > > > > > > > going to start generating the RC0. >>> > > > > > > > > > >>> > > > > > > > > > Please let me know if you have any concerns or reason >>> for >>> > > delay. >>> > > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > > >>> > > > > > -- >>> > > > > > Best regards, >>> > > > > > Andrew >>> > > > > > >>> > > > > > Unrest, ignorance distilled, nihilistic imbeciles - >>> > > > > > It's what we’ve earned >>> > > > > > Welcome, apocalypse, what’s taken you so long? >>> > > > > > Bring us the fitting end that we’ve been counting on >>> > > > > > - A23, Welcome, Apocalypse >>> > > > > > >>> > > >>> > >>> > >>> > -- >>> > *István Tóth* | Sr. Staff Software Engineer >>> > *Email*: st...@cloudera.com >>> > cloudera.com <https://www.cloudera.com> >>> > [image: Cloudera] <https://www.cloudera.com/> >>> > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: >>> > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: >>> Cloudera >>> > on LinkedIn] <https://www.linkedin.com/company/cloudera> >>> > ------------------------------ >>> > ------------------------------ >>> > >>> >>> >>> -- >>> Best regards, >>> Andrew >>> >>> Unrest, ignorance distilled, nihilistic imbeciles - >>> It's what we’ve earned >>> Welcome, apocalypse, what’s taken you so long? >>> Bring us the fitting end that we’ve been counting on >>> - A23, Welcome, Apocalypse >>> >>
