Yi Mei created HBASE-22946:
--
Summary: Fix TableNotFound when grant/revoke if AccessController
is not loaded
Key: HBASE-22946
URL: https://issues.apache.org/jira/browse/HBASE-22946
Project: HBase
Yi Mei created HBASE-22945:
--
Summary: Show quota infos in master UI
Key: HBASE-22945
URL: https://issues.apache.org/jira/browse/HBASE-22945
Project: HBase
Issue Type: Sub-task
Reporter:
+1
Signature, checksum: OK
Rat check: OK
Build from source: OK
Unit tests: OK
LTT 1M rows, standalone mode: OK
Changes, Release Notes: OK
Compatibility Report: OK
On Thu, Aug 29, 2019 at 2:22 AM Sakthi wrote:
> *+1 (Non-Binding)*
>
> Java Version - java-1.8.0-amazon-corretto-jdk_8.222.10-1
>
>
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,
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
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
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,
>
> I do not think we need to compile HBCK2 with every releases?
>
Well, not with every release, was thinking in doing it whenever an hbase
release breaks compatibility.
We just need
> make sure that it can work with all the releases.
This could be a solution as well, but I believe it would be
>
> 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.
>
Ideally yes, but that might not always be possible, as
I do not think we need to compile HBCK2 with every releases? We just need
make sure that it can work with all the releases. If there are missing
methods, we just tell users you can not use several features.
Wellington Chevreuil 于2019年8月29日周四
下午9:39写道：
> >
> > bq. what would folks think about
bq. I do not think we need to compile HBCK2 with every releases? We just
need
make sure that it can work with all the releases. If there are missing
methods, we just tell users you can not use several features.
We could do this but in this case we need to put version-specific checks
for each
David Mollitor created HBASE-22947:
--
Summary: Client Should Prompt For Additional Confirmation on
System Table DDL
Key: HBASE-22947
URL: https://issues.apache.org/jira/browse/HBASE-22947
Project:
Could also just make a release now of hbase-operator-tools (or in a week or
so when we should have hbck1+ coverage in place) built against an
up-to-date hbase release. It has the check version before running a feature
in place where it matters. Operators could use this on all currently
shipping
It does seem better to put it back in tree with core because core will be
branched, and would allow for the usual way we vary features and compatibility
by code line.
> On Aug 29, 2019, at 11:14 AM, Stack wrote:
>
>> On Thu, Aug 29, 2019 at 5:12 AM Peter Somogyi wrote:
>>
>> Hi everyone,
I like the last idea suggested by Stack. This way the core idea of keeping
both the dev process separate stays intact and also the operators have a
version of hbck to fix their clusters without worrying about compatibility
issues.
On Thu, Aug 29, 2019 at 2:03 PM Stack wrote:
> Could also just
[
https://issues.apache.org/jira/browse/HBASE-22941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-22941.
---
Fix Version/s: 2.2.2
2.1.7
2.3.0
3.0.0
Hadoop
[
https://issues.apache.org/jira/browse/HBASE-22949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-22949.
---
Fix Version/s: hbck2-1.0.0
Resolution: Fixed
Pushed.
> [HBCK2] Add lang3 as explicit dependency
>
On Thu, Aug 29, 2019 at 5: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
On Thu, Aug 29, 2019 at 7:34 AM Wellington Chevreuil <
wellington.chevre...@gmail.com> wrote:
> >
> > I do not think we need to compile HBCK2 with every releases?
> >
> Well, not with every release, was thinking in doing it whenever an hbase
> release breaks compatibility.
>
> We just need
> >
stack created HBASE-22949:
-
Summary: [HBCK2] Add lang3 as explicit dependency
Key: HBASE-22949
URL: https://issues.apache.org/jira/browse/HBASE-22949
Project: HBase
Issue Type: Bug
> > 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
Nick Dimiduk created HBASE-22948:
Summary: Report region size metric as a histogram
Key: HBASE-22948
URL: https://issues.apache.org/jira/browse/HBASE-22948
Project: HBase
Issue Type:
Nick Dimiduk created HBASE-22950:
Summary: Expose metrics for RegionNormalizer
Key: HBASE-22950
URL: https://issues.apache.org/jira/browse/HBASE-22950
Project: HBase
Issue Type: Improvement
With 7 +1s and at least 4 binding, the vote passes.
Let me push out the release and send a notice.
Thanks all for verifying the release candidate.
Peter Somogyi 于2019年8月29日周四 下午4:43写道：
> +1
>
> Signature, checksum: OK
> Rat check: OK
> Build from source: OK
> Unit tests: OK
> LTT 1M rows,
[
https://issues.apache.org/jira/browse/HBASE-22933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-22933.
---
Hadoop Flags: Reviewed
Resolution: Fixed
Pushed to branch-2.2+.
Thanks [~zghaobac] for
stack created HBASE-22951:
-
Summary: [HBCK2] hbase hbck throws IOE "No FileSystem for scheme:
hdfs"
Key: HBASE-22951
URL: https://issues.apache.org/jira/browse/HBASE-22951
Project: HBase
Issue
Shardul Singh created HBASE-22944:
-
Summary: TableNotFoundException: hbase:quota is thrown when
region server is restarted.
Key: HBASE-22944
URL: https://issues.apache.org/jira/browse/HBASE-22944
27 matches
Mail list logo
