Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Hadoop >> mail # dev >> [DISCUSS] Ensuring Consistent Behavior for Alternative Hadoop FileSystems + Workshop

Stephen Watt 2013-05-23, 23:52
Kun Ling 2013-05-24, 01:43
Brandon Li 2013-05-24, 17:56
Milind Bhandarkar 2013-05-24, 17:15
Konstantin Shvachko 2013-05-25, 00:08
Roman Shaposhnik 2013-05-29, 18:49
Andrew Purtell 2013-05-29, 19:30
Copy link to this message
Re: [DISCUSS] Ensuring Consistent Behavior for Alternative Hadoop FileSystems + Workshop
On 24 May 2013 00:52, Stephen Watt <[EMAIL PROTECTED]> wrote:

> Hi Folks
> Hadoop's pluggable filesystem architecture supports the ability to enable
> an alternate filesystem for use with Hadoop by writing a plugin for it. We
> now have several alternate filesystems that have Hadoop FileSystem plugins
> and because this isn't a very well understood topic, I've been working on a
> page on the project wiki to bring this all together -
> http://wiki.apache.org/hadoop/HCFS. At the same time, the Ambari project
> has been opening up Ambari to support any configured Hadoop FileSystem (as
> opposed to just HDFS) over at
> https://issues.apache.org/jira/browse/AMBARI-1817
> My team (over at Red Hat) have been working on writing a Hadoop FileSystem
> plugin for the glusterfs filesystem and have been finding that some of the
> expected semantics of the operations within the Abstract FileSystem class
> are a little ambiguous. With that said, we've joined Steve Loughran in
> attempting to clarify these for both the Hadoop 1.0 and the Hadoop 2.0
> FileSystem class over at https://issues.apache.org/jira/browse/HADOOP-9371
> It seems to me that once we had these semantics defined, it would be good
> for consistency of implementation if we could make sure they are well
> understood and properly implemented by the community of folks writing
> Hadoop FileSystem plugins. To that end, we might work to ensure that those
> semantics are tested within an exhaustive test framework that focuses on
> the abstract Hadoop FileSystem layer. Each FileSystem provider could run
> the tests to ensure their plugin implementation and behavior is consistent
> with the expectation. Perhaps a broader extension of
> https://issues.apache.org/jira/browse/HADOOP-9258.
I have a plan for starting those tests, pulling up the Swift ones when they
are checked in. Big tests that do scale, and that verify the assumptions
that MR, HBase &c are where we are weakest. The defacto definition of FS
sematics are the apps, and its them that currently find the problems (e.g
> If folks are interested in these goals, I could host a
> workshop/discussion/hackday in Mountain View to get local people together
> (perhaps a Google Hangout for the remote folks) to keep the ball rolling on
> the semantics discussion and test creation. As a side note, I think this
> could also turn out be quite an effective means of introducing FileSystem
> vendors to the ASF and getting them contributing to these aspects of the
> project.
Can we start with some G+ hangouts to get to know each other and have some
broader participation (myself, the others working on Swift, people who have
done S3 (Tom, some of the amazon folk), etc...), Then when a workshop is
held, it's got some clearer objectives "how do we test this". I would want
the FS semantics to be locked down in some online discussions/JIRA rather
than come back after a night's sleep to discover it had be defined with

Stephen Watt 2013-05-31, 20:00
Roman Shaposhnik 2013-05-31, 22:28
Stephen Watt 2013-06-06, 03:14
sanjay Radia 2013-06-07, 21:42
Stephen Watt 2013-06-10, 20:49
Andrew Wang 2013-06-10, 21:14
Stephen Watt 2013-06-14, 16:38
Andrew Wang 2013-06-14, 18:32
Andrew Purtell 2013-06-06, 08:59