> > what would folks think about going with an hbck2 alpha release? > > I'm fine with an alpha release but since "HBCK2 should continuously evolve" > it might be better to always use the latest codebase whenever you need to > use the tool.
We can't do this, as a matter of ASF policy. Anything that's supposed to be used by folks outside of the dev@hbase mailing list needs to have artifacts that the PMC has signed off on and placed into dist.a.o. It's fine if they're just source releases and we expect folks to always build it. But it can't be pointing them at the git repo. On Thu, Aug 29, 2019 at 8:09 AM Peter Somogyi <[email protected]> wrote: > > bq. Is it possible to put some hacks into HBCK2 to work around > the compatibility to fix the current state > > There are some classes around Replication which were introduced in 2.1.0+ > so I don't think we could easily solve it for 2.0. > For 2.1.1 the missing method is Hbck#scheduleServerCrashProcedure, probably > that could be solved with some workarounds or using reflection. > > bq. focus more on automation to let us know the next time we inevitably > break it again? ;) > > Sure! Based on this I think it should be a strong goal. We can set up > nightly builds for hbase-operator-tools repo that builds against the latest > development branches as well as checking compatibility with released > versions. > > bq. what would folks think about going with an hbck2 alpha release? > I'm fine with an alpha release but since "HBCK2 should continuously evolve" > it might be better to always use the latest codebase whenever you need to > use the tool. > > On Thu, Aug 29, 2019 at 2:30 PM Wellington Chevreuil < > [email protected]> wrote: > > > I would favour having hbck2 release branches. Temporary compatibility > > breaks at compile time may be inevitable if we always point to the latest > > release. That could cause problems for operators trying to build hbck2 (we > > are already seeing this happening with our support team). Another argument > > for starting having hbck2 releases is that we already have quite a few > > hbase 2 releases, yet, the main tool to fix inconsistencies is not easily > > available. And there's been considerable efforts lately to bring many of > > the fix options from hbck1 into hbck2, so what would folks think about > > going with an hbck2 alpha release? > > > > Em qui, 29 de ago de 2019 às 13:20, Josh Elser <[email protected]> > > escreveu: > > > > > I still like one HBCK2 release as the goal. > > > > > > Is it possible to put some hacks into HBCK2 to work around the > > > compatibility to fix the current state and focus more on automation to > > > let us know the next time we inevitably break it again? ;) > > > > > > On 8/29/19 8:12 AM, Peter Somogyi wrote: > > > > Hi everyone, > > > > > > > > This topic came up a couple of times already but now we reached a point > > > > when the recent HBCK2 is incompatible with older HBase releases, > > > > specifically 2.0.x, 2.1.0 and 2.1.1. When you build HBCK2 against one > > of > > > > the previously mentioned releases you will get compilation errors. (mvn > > > > clean install -DskipTests -Dhbase.version=2.0.6) > > > > > > > > Our previous goal was to maintain compatibility with HBCK2 and all > > HBase > > > 2 > > > > releases. Now we missed this target. > > > > > > > > One option that we could do is to have different branches/releases of > > > HBCK2 > > > > targeted for specific HBase releases (e.g. branch-2.0 version of > > HBCK2). > > > > This probably makes the development on HBCK2 a bit harder since we'll > > > have > > > > to take care of multiple branches. > > > > > > > > Another option I could think of is to always build HBCK2 with the > > latest > > > > HBase release but have version checks on individual commands where we > > > could > > > > decide if it is supported on that release line. > > > > > > > > What are your opinions on this? > > > > > > > > Thanks, > > > > Peter > > > > > > > > >
