Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-08-07 Thread Toshihiro Suzuki
Hi Josh, I’m interested in this, too. I’ll start to read and follow what you suggested to Jack. Thanks, Toshi > On Aug 7, 2018, at 09:12, Jack Bearden wrote: > > Thanks Josh that was helpful. I'll start doing some of my own research > around these topics and look into that Ratis ticket. Much

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-08-06 Thread Jack Bearden
Thanks Josh that was helpful. I'll start doing some of my own research around these topics and look into that Ratis ticket. Much appreciated! On Mon, Aug 6, 2018 at 8:04 AM, Josh Elser wrote: > Yup, replication is a big one to "unravel". Repeating myself from a branch > in the thread, but I'd

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-08-06 Thread Josh Elser
Yup, replication is a big one to "unravel". Repeating myself from a branch in the thread, but I'd expect some initial suggestions on what a new API could be this week. Certainly the first draft won't be the final -- would be great to get your input after your AsyncWAL work, Duo. Using AWS

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-08-06 Thread Josh Elser
Thanks for your interest, Jack. Taking a read through the "design doc" and related discussion is a good starting point. Re-linked here for your convenience [1] https://issues.apache.org/jira/browse/HBASE-20951 has a break-down of work items. The first thing we need to work on is the WAL API.

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-08-04 Thread Duo Zhang
Yes, maybe we could write WAL to SQS and HFile to S3, then we can deploy HBase on AWS without any local storage volumes... But we also need a good abstraction for Replication, as the current design is file based... 2018-07-27 1:28 GMT+08:00 Zach York : > I would REALLY hope that the WAL

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-08-03 Thread Jack Bearden
Great work! I'm excited about this feature and want to help with development. What do you guys suggest are the best topics to ramp up in preparation for these upcoming sprints? On Fri, Aug 3, 2018 at 10:18 AM, Josh Elser wrote: > Yup, we're on the same page :) > > > On 7/26/18 1:28 PM, Zach

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-08-03 Thread Josh Elser
Yup, we're on the same page :) On 7/26/18 1:28 PM, Zach York wrote: I would REALLY hope that the WAL interface/API changes would go into master even if the feature work for Ratis is going in a feature branch. Not only would this enable other backends to be developed in parallel with the Ratis

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-07-26 Thread Zach York
I would REALLY hope that the WAL interface/API changes would go into master even if the feature work for Ratis is going in a feature branch. Not only would this enable other backends to be developed in parallel with the Ratis solution if there are other good fits for a non-HDFS WAL, but also it

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-07-26 Thread Josh Elser
On 7/26/18 1:00 AM, Stack wrote: All this said, I'd like to start moving toward the point where we start breaking out this work into a feature-branch off of master and start building code. My hope is that this is amenable to everyone, with the acknowledge that the Ratis work is considered

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-07-25 Thread Stack
On Wed, Jul 25, 2018 at 11:55 AM Josh Elser wrote: > ... > My biggest take-away is that I complicated this document by tying it too > closely with "HBase on Cloud", treating the WAL+Ratis LogService as the > only/biggest thing to figure out. This was inaccurate and overly bold of > me: I

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-07-25 Thread Josh Elser
Thanks, Zach! I like your suggestion about project updates. I sincerely hope that this can be something transparent enough that folks who want to follow-on and participate in implementation can do so. Let me think about how to drive this better. On 7/25/18 3:55 PM, Zach York wrote: +1 to

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-07-25 Thread Josh Elser
Thanks, Andrew. I was really upset that I was butting heads with you when I would have previously thought that I had a design which was in line with something you would have called "good". I will wholly take the blame in not having an as-clear-as-possible design doc. I am way down in the

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-07-25 Thread Zach York
+1 to starting the work. I think most of the concerns can be figured out on the JIRAs and we can have a project update every X weeks if enough people are interested. I also agree to frame the feature correctly. Decoupling from a HDFS WAL or WAL on Ratis would be more appropriate names that would

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-07-25 Thread Andrew Purtell
> My biggest take-away is that I complicated this document by tying it too > closely with "HBase on Cloud", treating the WAL+Ratis LogService as the only/biggest thing to figure out. Understanding this now helps a lot to understand better the positions taken from the doc. At first glance it

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-07-25 Thread Josh Elser
Let me give an update on-list for everyone: First and foremost, thank you very much to everyone who took the time to read this, with an extra thanks to those who participated in discussion. There were lots of great points raised. Some about things that were unclear in the doc, and others

[DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

2018-07-13 Thread Josh Elser
Hi all, A long time ago, I shared a document about a (I'll call it..) "vision" where we make some steps towards decoupling HBase from HDFS in an effort to make deploying HBase on Cloud IaaS providers a bit easier (operational simplicity, effective use of common IaaS paradigms, etc).