[
https://issues.apache.org/jira/browse/HBASE-24175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Stack resolved HBASE-24175.
---
Resolution: Fixed
Re-resovling after attaching second one-liner addendum.
> [Flakey Tests]
[
https://issues.apache.org/jira/browse/HBASE-24175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Stack reopened HBASE-24175:
---
Reopen to apply addendum. Nightly just failed with this:
health checks / yetus jdk8 hadoop3
[
https://issues.apache.org/jira/browse/HBASE-24193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reid Chan resolved HBASE-24193.
---
Hadoop Flags: Reviewed
Resolution: Fixed
> BackPort HBASE-18651 to branch-1
>
This should work for locally attached storage for sure.
On Wed, Apr 15, 2020 at 3:52 PM Vladimir Rodionov
wrote:
> FileOutputStream.getFileChannel().force(true) will get all durability we
> need. Just a simple code change?
>
>
> On Wed, Apr 15, 2020 at 12:32 PM Andrew Purtell
> wrote:
>
>>
FileOutputStream.getFileChannel().force(true) will get all durability we
need. Just a simple code change?
On Wed, Apr 15, 2020 at 12:32 PM Andrew Purtell
wrote:
> This thread talks of “durability” via filesystem characteristics but also
> for single system quick Start type deployments. For
[
https://issues.apache.org/jira/browse/HBASE-24183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Huaxiang Sun resolved HBASE-24183.
--
Resolution: Fixed
Pushed the patch, will monitor flaky test board.
> [flakey test]
Thank you, Yu. Hello, everyone --my apologies for seemingly ignoring you.
Misty Linville contacted me earlier about this, but I've been snagged with some
urgent business, thus my delayed response.
I'll be happy to support your anniversary, and can publish a Foundation
announcement, similar to
This thread talks of “durability” via filesystem characteristics but also for
single system quick Start type deployments. For durability we need multi server
deployments. No amount of hacking a single system deployment is going to give
us durability as users will expect (“don’t lose my data”).
On Wed, Apr 15, 2020 at 10:28 AM Andrew Purtell wrote:
> Nick's mail doesn't make a distinction between avoiding data loss via
> typical tmp cleaner configurations, unfortunately adjacent to mention of
> "durability", and real data durability, which implies more than what a
> single system
On Wed, Apr 15, 2020 at 10:05 AM Sean Busbey wrote:
> I think the first assumption no longer holds. Especially with the move
> to flexible compute environments I regularly get asked by folks what
> the smallest HBase they can start with for production. I can keep
> saying 3/5/7 nodes or whatever
[
https://issues.apache.org/jira/browse/HBASE-24175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Stack resolved HBASE-24175.
---
Resolution: Fixed
Pushed addendum to branch-2.2+. Re-resolving. Lets see if this catches
Yeah, the TLP announcement date is good for that.
thanks,
esteban.
--
Cloudera, Inc.
On Wed, Apr 15, 2020 at 12:07 PM Sean Busbey wrote:
> That was probably when our community was still covered under the
> Hadoop project. Essentially our version of being in the incubator.
>
> This is when
> I propose changing the default value of `hbase.tmp.dir` as shipped in the
> default hbase-site.xml to be simply `tmp`, as I documented in my change on
> HBASE-24106. That way it's not hidden somewhere and it's self-contained to
> this unpacking of the source/binary distribution.
+1, great
> We could start with a fork of
> RawLocalFileSystem (which will call OutputStream flush operations in
> response to hflush/hsync) that properly advertises its
> StreamCapabilities to say that it supports the operations we need.
This is a worthy option to pursue.
Nick's mail doesn't make a
On Wed, Apr 15, 2020 at 12:03 PM Nick Dimiduk wrote:
>
> Branching off this subject from the original thread.
>
> On Wed, Apr 15, 2020 at 9:56 AM Andrew Purtell
> wrote:
>
> > Quick Start and Production are exclusive configurations.
> >
>
> Yes absolutely.
>
> Quick Start, as you say, should
That was probably when our community was still covered under the
Hadoop project. Essentially our version of being in the incubator.
This is when we became our own TLP:
https://whimsy.apache.org/board/minutes/HBase.html#2010-04-21
On Wed, Apr 15, 2020 at 11:25 AM Vladimir Rodionov
wrote:
>
>
I think the first assumption no longer holds. Especially with the move
to flexible compute environments I regularly get asked by folks what
the smallest HBase they can start with for production. I can keep
saying 3/5/7 nodes or whatever but I guarantee there are folks who
want to and will run
Branching off this subject from the original thread.
On Wed, Apr 15, 2020 at 9:56 AM Andrew Purtell
wrote:
> Quick Start and Production are exclusive configurations.
>
Yes absolutely.
Quick Start, as you say, should have as few steps to up and running as
> possible.
>
> Production requires a
On Wed, Apr 15, 2020 at 9:25 AM Vladimir Rodionov
wrote:
> 2020 - 10 = 2010. As far as I remember I joined HBase community in 2009 :)
> and I am pretty sure that Mr. Stack did it even earlier.
>
IIRC, 2010 is when HBase graduated from being a Hadoop sub-project and
became a Apache Top-Level
Quick Start and Production are exclusive configurations.
Quick Start, as you say, should have as few steps to up and running as
possible.
Production requires a real distributed filesystem for persistence and that
means HDFS and that means, whatever the provisioning and deployment and process
Hi folks,
I'd like to bring up the topic of the experience of new users as it
pertains to use of the `LocalFileSystem` and its associated (lack of) data
durability guarantees. By default, an unconfigured HBase runs with its root
directory on a `file:///` path. This patch is picked up as an
2020 - 10 = 2010. As far as I remember I joined HBase community in 2009 :)
and I am pretty sure that Mr. Stack did it even earlier.
Best regards,
Vlad
On Wed, Apr 15, 2020 at 5:57 AM Yu Li wrote:
> Dear all,
>
> Since our project has reached its 10th birthday, and 10 years is definitely
> a
[
https://issues.apache.org/jira/browse/HBASE-24175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Stack reopened HBASE-24175:
---
The patch here doesn't get all places where yarn is using /tmp. The 2.3 build
failed with the
Istvan Toth created HBASE-24197:
---
Summary: TestHttpServer.testBindAddress failure with latest jetty
Key: HBASE-24197
URL: https://issues.apache.org/jira/browse/HBASE-24197
Project: HBase
Issue
Dear all,
Since our project has reached its 10th birthday, and 10 years is definitely
a great milestone, I propose to arrange some special (virtual) events for
celebration. What comes into my mind include:
* Open threads to collect voices from our dev/user mailing list, like "what
do you want to
Reid Chan created HBASE-24196:
-
Summary: [Shell] Add rsgroup command in hbase shell
Key: HBASE-24196
URL: https://issues.apache.org/jira/browse/HBASE-24196
Project: HBase
Issue Type: Improvement
[
https://issues.apache.org/jira/browse/HBASE-24112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reid Chan resolved HBASE-24112.
---
Hadoop Flags: Reviewed
Resolution: Fixed
> [RSGroup] Support renaming rsgroup
>
Viraj Jasani created HBASE-24195:
Summary: Admin.getRegionServers() should return live servers
excluding decom RS optionally
Key: HBASE-24195
URL: https://issues.apache.org/jira/browse/HBASE-24195
Viraj Jasani created HBASE-24194:
Summary: Refactor BufferedEncodedSeeker anonymous classes to named
inner class
Key: HBASE-24194
URL: https://issues.apache.org/jira/browse/HBASE-24194
Project: HBase
Lokesh Khurana created HBASE-24193:
--
Summary: BackPort (ChaosMonkeyRunner expose the chaos monkey
runner it creates
Key: HBASE-24193
URL: https://issues.apache.org/jira/browse/HBASE-24193
Project:
Lokesh Khurana created HBASE-24192:
--
Summary: Let ChaosMonkeyRunner expose the chaos monkey runner it
creates for branch-1
Key: HBASE-24192
URL: https://issues.apache.org/jira/browse/HBASE-24192
31 matches
Mail list logo