[jira] [Created] (HBASE-24362) Remove/Retain deprecated configs

[Anoop Sam John (Jira)]

Anoop Sam John created HBASE-24362:
--

 Summary: Remove/Retain deprecated configs
 Key: HBASE-24362
 URL: https://issues.apache.org/jira/browse/HBASE-24362
 Project: HBase
  Issue Type: Umbrella
Reporter: Anoop Sam John
 Fix For: 3.0.0-alpha-1


This umbrella issue is to discuss and decide on each config which are 
deprecated in 2.x line (Or even before itself). Whether we can completely 
remove them from code. If so whether we need have some migration tool/step.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-24361) Make `RESTApiClusterManager` more resilient

[Nick Dimiduk (Jira)]

Nick Dimiduk created HBASE-24361:


 Summary: Make `RESTApiClusterManager` more resilient
 Key: HBASE-24361
 URL: https://issues.apache.org/jira/browse/HBASE-24361
 Project: HBase
  Issue Type: Test
  Components: integration tests
Affects Versions: 2.3.0
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk


The Cloudera Manager API client in {{RESTApiClusterManager}} appears to assume 
that API calls sent to CM for process commands block on command completion. 
However, these commands are "asynchronous," queuing work in the background for 
execution. Update the client to track command submission and block on 
completion of that commandId. This allows this {{ClusterManager}} to conform to 
the expectations of the {{Actions}} that invoke it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-24360) RollingBatchRestartRsAction loses track of dead servers

[Nick Dimiduk (Jira)]

Nick Dimiduk created HBASE-24360:


 Summary: RollingBatchRestartRsAction loses track of dead servers
 Key: HBASE-24360
 URL: https://issues.apache.org/jira/browse/HBASE-24360
 Project: HBase
  Issue Type: Test
  Components: integration tests
Affects Versions: 2.3.0
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk


{{RollingBatchRestartRsAction}} doesn't handle failure cases when tracking its 
list of dead servers. The original author believed that a failure to restart 
would result in a retry. However, by removing the dead server from the failed 
list prematurely, that state is lost, and retry of that server never occurs. 
Because this action doesn't ever look back to the current state of the cluster, 
relying only on its local state for the current action invocation, it never 
realizes the abandoned server is still dead. Instead, be more careful to only 
remove the dead server from the list when the {{startRs}} invocation claims to 
have been successful.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-24165) maxPoolSize is logged incorrectly in ByteBufferPool

[Michael Stack (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-24165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Stack resolved HBASE-24165.
---
Fix Version/s: 2.2.5
 Hadoop Flags: Reviewed
   Resolution: Fixed

Merged. Thanks for the patch [~pankajkumar]

> maxPoolSize is logged incorrectly in ByteBufferPool
> ---
>
> Key: HBASE-24165
> URL: https://issues.apache.org/jira/browse/HBASE-24165
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.2.4
>Reporter: Pankaj Kumar
>Assignee: Pankaj Kumar
>Priority: Minor
> Fix For: 2.2.5
>
>
> In ByteBufferPool _maxPoolSize_ is converted into byte format,
> https://github.com/apache/hbase/blob/a521a80c4b9a8b0749c368d1ff66fea2ed2d77a2/hbase-common/src/main/java/org/apache/hadoop/hbase/io/ByteBufferPool.java#L85
>  
> Currently maxPoolSize is logged as below,
> 2020-04-10 14:20:56,000 INFO  [Time-limited test] io.ByteBufferPool(83): 
> Created with bufferSize=64 KB and maxPoolSize=320 B



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-24354) Make it so can make an hbase1 schema and hbase2 schema equate

[Michael Stack (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-24354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Stack resolved HBASE-24354.
---
Fix Version/s: 2.3.0
   3.0.0-alpha-1
 Assignee: Michael Stack
   Resolution: Fixed

Pushed after testing an hbase1 replicating to an hbase2.

> Make it so can make an hbase1 schema and hbase2 schema equate
> -
>
> Key: HBASE-24354
> URL: https://issues.apache.org/jira/browse/HBASE-24354
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Michael Stack
>Assignee: Michael Stack
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.3.0
>
>
> Currently, NEW_VERSION_BEHAVIOR displays in hbase2 schemas with default value 
> of 'false'. This default is added whenever we create a new column descriptor. 
> Its not needed. We'll return default if empty or undefined. Meantime, since 
> this is not defined in hbase1, it makes it so we can't make equivalent 
> schemas so not possible to replicate from hbase1 to hbase2.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Recent experience with Chaos Monkey?

[Nick Dimiduk]

Thanks Zach.

> It actually performs even worse in this case in my experience since Chaos
monkey can consider the failure mechanism to have failed (and eventually
times out) because the process is too quick to recover (or the recovery
fails because the process is already running). The only way I was able to
get it to run was to disable the process that automatically restarts killed
processes in my system.

Interesting observation.

> This brings up a discussion on whether the ITBLL (or whatever process)
should even continue if either a killing or recovering action failed.
I would argue that invalidates the entire test, but it might not be obvious
it failed unless you were watching the logs as it went.

I'm coming to a similar conclusion -- failure in the orchestration layer
should invalidate the test.

On Thu, May 7, 2020 at 5:27 PM Zach York 
wrote:

> I should note that I was using HBase 2.2.3 to test.
>
> On Thu, May 7, 2020 at 5:26 PM Zach York 
> wrote:
>
> > I recently ran ITBLL with Chaos monkey[1] against a real HBase
> > installation (EMR). I initially tried to run it locally, but couldn't get
> > it working and eventually gave up.
> >
> > > So I'm curious if this matches others' experience running the monkey.
> For
> > example, do you have an environment more resilient than mine, one where
> an
> > external actor is restarting downed processed without the monkey action's
> > involvement?
> >
> > It actually performs even worse in this case in my experience since Chaos
> > monkey can consider the failure mechanism to have failed (and eventually
> > times out)
> > because the process is too quick to recover (or the recovery fails
> because
> > the process is already running). The only way I was able to get it to run
> > was to disable
> > the process that automatically restarts killed processes in my system.
> >
> > One other thing I hit was the validation for a suspended process was
> > incorrect so if chaos monkey tried to suspend the process the run would
> > fail. I'll put up a JIRA for that.
> >
> > This brings up a discussion on whether the ITBLL (or whatever process)
> > should even continue if either a killing or recovering action failed. I
> > would argue that invalidates the entire test,
> > but it might not be obvious it failed unless you were watching the logs
> as
> > it went.
> >
> > Thanks,
> > Zach
> >
> >
> > [1] sudo -u hbase hbase
> > org.apache.hadoop.hbase.test.IntegrationTestBigLinkedList -m
> serverKilling
> > loop 4 2 100 ${RANDOM} 10
> >
> > On Thu, May 7, 2020 at 5:05 PM Nick Dimiduk  wrote:
> >
> >> Hello,
> >>
> >> Does anyone have recent experience running Chaos Monkey? Are you running
> >> against an external cluster, or one of the other modes? What monkey
> >> factory
> >> are you using? Any property overrides? A non-default ClusterManager?
> >>
> >> I'm trying to run ITBLL with chaos against branch-2.3 and I'm not having
> >> much luck. My environment is an "external" cluster, 4 racks of 4 hosts
> >> each, the relatively simple "serverKilling" factory with
> >> `rolling.batch.suspend.rs.ratio = 0.0`. So, randomly kill various hosts
> >> on
> >> various scheduled, plus some balancer play mixed in; no process
> >> suspension.
> >>
> >> Running for any length of time (~30 minutes) the chaos monkey eventually
> >> terminates between a majority and all of the hosts in the cluster. My
> logs
> >> are peppered with warnings such as the below. There are other variants.
> As
> >> far as I can tell, actions are intended to cause some harm and then
> >> restore
> >> state after themselves. In practice, the harm is successful but
> >> restoration
> >> rarely succeeds. Mostly these actions are "safeguarded" but this 60-sec
> >> timeout. The result is a methodical termination of the cluster.
> >>
> >> So I'm curious if this matches others' experience running the monkey.
> For
> >> example, do you have an environment more resilient than mine, one where
> an
> >> external actor is restarting downed processed without the monkey
> action's
> >> involvement? Is the monkey designed to run only in such an environment?
> >> These timeouts are configurable; are you cranking them way up?
> >>
> >> Any input you have would be greatly appreciated. This is my last major
> >> action item blocking initial 2.3.0 release candidates.
> >>
> >> Thanks,
> >> Nick
> >>
> >> 20/05/05 21:19:29 WARN policies.Policy: Exception occurred during
> >> performing action: java.io.IOException: did timeout 6ms waiting for
> >> region server to start: host-a.example.com
> >> at
> >>
> >>
> org.apache.hadoop.hbase.HBaseCluster.waitForRegionServerToStart(HBaseCluster.java:163)
> >> at
> >> org.apache.hadoop.hbase.chaos.actions.Action.startRs(Action.java:228)
> >> at
> >>
> >>
> org.apache.hadoop.hbase.chaos.actions.RestartActionBaseAction.gracefulRestartRs(RestartActionBaseAction.java:70)
> >> at
> >>
> >>
> 

[jira] [Resolved] (HBASE-24256) When fixOverlap hits the max region limit, it is possible to include the same region in multiple merge request

[Huaxiang Sun (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-24256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Huaxiang Sun resolved HBASE-24256.
--
Fix Version/s: 2.4.0
   2.3.0
   3.0.0-alpha-1
   Resolution: Fixed

Pushed the patch to 2.3, branch-2, and master.

> When fixOverlap hits the max region limit, it is possible to include the same 
> region in multiple merge request
> --
>
> Key: HBASE-24256
> URL: https://issues.apache.org/jira/browse/HBASE-24256
> Project: HBase
>  Issue Type: Improvement
>  Components: hbck2
>Affects Versions: 3.0.0-alpha-1, 2.3.0, 2.4.0
>Reporter: Huaxiang Sun
>Assignee: Huaxiang Sun
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.3.0, 2.4.0
>
>
> If the same region is included in multiple merge requests, the first merge 
> cleans up the region state, the second merge request will fail with error msg 
> "No state for region ". The algo needs to be improved to make sure the 
> same region is not included in multi merge requests.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-24351) Backport HBASE-24302 to branch-1

[Wellington Chevreuil (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-24351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wellington Chevreuil resolved HBASE-24351.
--
Resolution: Fixed

Pushed to branch-1 and branch-1.4

> Backport HBASE-24302 to branch-1
> 
>
> Key: HBASE-24351
> URL: https://issues.apache.org/jira/browse/HBASE-24351
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 1.7.0, 1.4.13
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Major
> Fix For: 1.7.0, 1.4.14
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-24355) Fix typos in the HStore#compact annotation

[Viraj Jasani (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-24355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Viraj Jasani resolved HBASE-24355.
--
Fix Version/s: 2.2.5
   1.4.14
   2.1.10
   1.7.0
   2.3.0
   3.0.0-alpha-1
 Hadoop Flags: Reviewed
   Resolution: Fixed

Pushed to master, branch-2, 2.3, 2.2, 2.1, branch-1, 1.4. Thanks [~gk_coder].

> Fix typos in the HStore#compact annotation
> --
>
> Key: HBASE-24355
> URL: https://issues.apache.org/jira/browse/HBASE-24355
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 1.2.6.1, 1.3.6, 1.4.13
>Reporter: kangkang.guo
>Assignee: kangkang.guo
>Priority: Minor
> Fix For: 3.0.0-alpha-1, 2.3.0, 1.7.0, 2.1.10, 1.4.14, 2.2.5
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Celebrating our 10th birthday for Apache HBase

[Mich Talebzadeh]

Hi,

I will be presenting on Hbase to one of the major European banks this
Friday  15th May.

Does anyone have latest bullet points on new features of HBase so I can add
them to my presentation material.

Many thanks,

Dr Mich Talebzadeh


[image: image.png]




LinkedIn * 
https://www.linkedin.com/profile/view?id=AAEWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw
*



*Disclaimer:* Use it at your own risk. Any and all responsibility for any
loss, damage or destruction of data or any other property which may arise
from relying on this email's technical content is explicitly disclaimed.
The author will in no case be liable for any monetary damages arising from
such loss, damage or destruction.




On Sat, 2 May 2020 at 08:19, Mich Talebzadeh 
wrote:

> Hi,
>
> I have worked with Hbase for many years and I think it is a great product.
> it does what it says on the tin so to speak.
>
> Ironically if you look around the NoSQL competitors, most of them are
> supported by start-ups, whereas Hbase is only supported as part of Apache
> suite of products by vendors like Cloudera, Hortonworks MapR etc.
>
> For those who would prefer to use SQL on top, there is Apache Phoenix
> around which makes life easier for most SQL savvy world to work on Hbase.
> Problem solved
>
> For TCO, Hbase is still value for money compared to others. You don't need
> expensive RAM or SSD with Hbase. That makes it easy to onboard it in no
> time. Also Hbase can be used in a variety of different business
> applications, whereas other commercial ones  are focused on narrower niche
> markets.
>
> Least but last happy 10th anniversary and hope Hbase will go form
> strength to strength and we will keep using it for years to come!
>
>
>
>
>
>
> Dr Mich Talebzadeh
>
>
>
> LinkedIn * 
> https://www.linkedin.com/profile/view?id=AAEWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw
> *
>
>
>
> http://talebzadehmich.wordpress.com
>
>
> *Disclaimer:* Use it at your own risk. Any and all responsibility for any
> loss, damage or destruction of data or any other property which may arise
> from relying on this email's technical content is explicitly disclaimed.
> The author will in no case be liable for any monetary damages arising from
> such loss, damage or destruction.
>
>
>
>
> On Sat, 2 May 2020 at 07:28, Yu Li  wrote:
>
>> Dear HBase developers and users,
>> 亲爱的HBase开发者和用户们，
>>
>> It has been a decade since Apache HBase became an Apache top level project
>> [1]. Ten years is a big milestone and deserves a good celebration. Do you
>> have anything to say to us? Maybe some wishes, good stories or just a
>> happy
>> birthday blessing? Looking forward to your voices.
>>
>> 大家好！距离 HBase 成为 Apache 顶级项目 (TLP) 已经过去了整整 10 年
>> [1]，这是一个值得纪念的里程碑。在这个特殊的时刻，您有什么想对 HBase 说的吗？分享您和 HBase 之间发生的故事，表达您对 HBase
>> 的期待，或者是一句简单的“生日快乐”祝福？期待听到您的声音。
>>
>> Best Regards,
>> Yu (on behalf of the Apache HBase PMC)
>>
>> 祝好！
>> Yu (代表Apache HBase PMC)
>>
>> [1] https://whimsy.apache.org/board/minutes/HBase.html#2010-04-21
>>
>

[jira] [Resolved] (HBASE-23943) Rubocop configuration needs updated

[Peter Somogyi (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-23943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Somogyi resolved HBASE-23943.
---
Fix Version/s: 2.2.5
   Resolution: Fixed

Pushed to branch-2.2.

> Rubocop configuration needs updated
> ---
>
> Key: HBASE-23943
> URL: https://issues.apache.org/jira/browse/HBASE-23943
> Project: HBase
>  Issue Type: Test
>  Components: build
>Affects Versions: 3.0.0-alpha-1, 2.3.0, 1.7.0
>Reporter: Nick Dimiduk
>Assignee: Jan Hentschel
>Priority: Minor
> Fix For: 3.0.0-alpha-1, 2.3.0, 1.7.0, 2.2.5
>
>
> Looking at the general check output on 
> [nightly/master|https://builds.apache.org/blue/organizations/jenkins/HBase%20Nightly/detail/master/1654/pipeline/96/],
>  it looks like our {{.rubocop.yaml}} configuration file has drifted from the 
> syntax expected by our current version of the tool. Lots of errors like the 
> following:
> {noformat}
> [2020-03-05T15:36:27.538Z] Running rubocop against identified ruby scripts.
> [2020-03-05T15:36:27.538Z] .rubocop.yml: Metrics/LineLength has the wrong 
> namespace - should be Layout
> [2020-03-05T15:36:27.538Z] Error: The `Layout/IndentHeredoc` cop has been 
> renamed to `Layout/HeredocIndentation`.
> [2020-03-05T15:36:27.538Z] (obsolete configuration found in .rubocop.yml, 
> please update it)
> [2020-03-05T15:36:27.538Z] .rubocop.yml: Metrics/LineLength has the wrong 
> namespace - should be Layout
> [2020-03-05T15:36:27.538Z] Error: The `Layout/IndentHeredoc` cop has been 
> renamed to `Layout/HeredocIndentation`.
> [2020-03-05T15:36:27.538Z] (obsolete configuration found in .rubocop.yml, 
> please update it)
> ...
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Reopened] (HBASE-23943) Rubocop configuration needs updated

[Peter Somogyi (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-23943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Somogyi reopened HBASE-23943:
---

Reopening to backport to branch-2.2.

> Rubocop configuration needs updated
> ---
>
> Key: HBASE-23943
> URL: https://issues.apache.org/jira/browse/HBASE-23943
> Project: HBase
>  Issue Type: Test
>  Components: build
>Affects Versions: 3.0.0-alpha-1, 2.3.0, 1.7.0
>Reporter: Nick Dimiduk
>Assignee: Jan Hentschel
>Priority: Minor
> Fix For: 3.0.0-alpha-1, 2.3.0, 1.7.0
>
>
> Looking at the general check output on 
> [nightly/master|https://builds.apache.org/blue/organizations/jenkins/HBase%20Nightly/detail/master/1654/pipeline/96/],
>  it looks like our {{.rubocop.yaml}} configuration file has drifted from the 
> syntax expected by our current version of the tool. Lots of errors like the 
> following:
> {noformat}
> [2020-03-05T15:36:27.538Z] Running rubocop against identified ruby scripts.
> [2020-03-05T15:36:27.538Z] .rubocop.yml: Metrics/LineLength has the wrong 
> namespace - should be Layout
> [2020-03-05T15:36:27.538Z] Error: The `Layout/IndentHeredoc` cop has been 
> renamed to `Layout/HeredocIndentation`.
> [2020-03-05T15:36:27.538Z] (obsolete configuration found in .rubocop.yml, 
> please update it)
> [2020-03-05T15:36:27.538Z] .rubocop.yml: Metrics/LineLength has the wrong 
> namespace - should be Layout
> [2020-03-05T15:36:27.538Z] Error: The `Layout/IndentHeredoc` cop has been 
> renamed to `Layout/HeredocIndentation`.
> [2020-03-05T15:36:27.538Z] (obsolete configuration found in .rubocop.yml, 
> please update it)
> ...
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-24359) Optionally ignore edits for deleted CFs for replication.

[Sun Xin (Jira)]

Sun Xin created HBASE-24359:
---

 Summary: Optionally ignore edits for deleted CFs for replication.
 Key: HBASE-24359
 URL: https://issues.apache.org/jira/browse/HBASE-24359
 Project: HBase
  Issue Type: Improvement
  Components: Replication
Affects Versions: 2.2.4
Reporter: Sun Xin
Assignee: Sun Xin
 Fix For: 3.0.0-alpha-1


Replication will be stuck after we delete CFs from both the source and the 
sink, if the source still has outstanding edits that now it could not get rid 
of. Now all replication is backed up behind these unreplicatable edits.
We should have an option to ignore edits for deleted CFs at the source.

This issue is similar to 
[HBASE-12091|https://issues.apache.org/jira/browse/HBASE-12091]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-24358) Move hbase-filesystem to hbase-thirdparty-3.3.0

[Peter Somogyi (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-24358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Somogyi resolved HBASE-24358.
---
Resolution: Duplicate

> Move hbase-filesystem to hbase-thirdparty-3.3.0
> ---
>
> Key: HBASE-24358
> URL: https://issues.apache.org/jira/browse/HBASE-24358
> Project: HBase
>  Issue Type: Task
>  Components: Filesystem Integration
>Affects Versions: hbase-filesystem-1.0.0-alpha2
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Major
> Fix For: hbase-filesystem-1.0.0-alpha2
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-24358) Move hbase-filesystem to hbase-thirdparty-3.3.0

[Peter Somogyi (Jira)]

Peter Somogyi created HBASE-24358:
-

 Summary: Move hbase-filesystem to hbase-thirdparty-3.3.0
 Key: HBASE-24358
 URL: https://issues.apache.org/jira/browse/HBASE-24358
 Project: HBase
  Issue Type: Task
  Components: Filesystem Integration
Affects Versions: hbase-filesystem-1.0.0-alpha2
Reporter: Peter Somogyi
Assignee: Peter Somogyi
 Fix For: hbase-filesystem-1.0.0-alpha2






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-24357) Move hbase-filesystem to hbase-thirdparty-3.3.0

[Peter Somogyi (Jira)]

Peter Somogyi created HBASE-24357:
-

 Summary: Move hbase-filesystem to hbase-thirdparty-3.3.0
 Key: HBASE-24357
 URL: https://issues.apache.org/jira/browse/HBASE-24357
 Project: HBase
  Issue Type: Task
Reporter: Peter Somogyi
Assignee: Peter Somogyi






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-24356) Move hbase-connectors to hbase-thirdparty-3.3.0

[Peter Somogyi (Jira)]

Peter Somogyi created HBASE-24356:
-

 Summary: Move hbase-connectors to hbase-thirdparty-3.3.0
 Key: HBASE-24356
 URL: https://issues.apache.org/jira/browse/HBASE-24356
 Project: HBase
  Issue Type: Task
  Components: hbase-connectors
Affects Versions: connector-1.0.1
Reporter: Peter Somogyi
Assignee: Peter Somogyi
 Fix For: connector-1.0.1






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-24349) Use rubocop 0.81.0 in Dockerfile

[Peter Somogyi (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-24349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Somogyi resolved HBASE-24349.
---
Resolution: Fixed

Pushed to branch-2.2.

> Use rubocop 0.81.0 in Dockerfile
> 
>
> Key: HBASE-24349
> URL: https://issues.apache.org/jira/browse/HBASE-24349
> Project: HBase
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.2.5
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Blocker
> Fix For: 2.2.5
>
>
> Nightly branch-2.2 docker image is broken as a result of rubocop 0.82.0 which 
> dropped support for Ruby 2.3



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-24355) Fix typos in the HStore#compact annotation

[kangkang.guo (Jira)]

kangkang.guo created HBASE-24355:


 Summary: Fix typos in the HStore#compact annotation
 Key: HBASE-24355
 URL: https://issues.apache.org/jira/browse/HBASE-24355
 Project: HBase
  Issue Type: Improvement
Affects Versions: 1.4.13, 1.3.6, 1.2.6.1
Reporter: kangkang.guo






--
This message was sent by Atlassian Jira
(v8.3.4#803005)