gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] [Gluster-users] PLEASE READ ! We need your opinion.


From: John Mark Walker
Subject: Re: [Gluster-devel] [Gluster-users] PLEASE READ ! We need your opinion. GSOC-2014 and the Gluster community
Date: Thu, 13 Mar 2014 14:19:02 -0400 (EDT)

----- Original Message -----

> Welcome, Carlos.  I think it's great that you're taking initiative here.

+1 - I love enthusiastic fresh me^H^H^H^H^H^H^H^Hcommunity members! :)


> However, it's also important to set proper expectations for what a GSoC
> intern
> could reasonably be expected to achieve.  I've seen some amazing stuff out of
> GSoC, but if we set the bar too high then we end up with incomplete code and
> the student doesn't learn much except frustration.

This. The reason we haven't really participated in GSoC is not because we don't 
want to - it's because it's exceptionally difficult for a project of our scope, 
but that doesn't mean there aren't any possibilities. As an example, last year 
the Open Source Lab at OSU worked with a student to create an integration with 
Ganeti, which was mostly successful, and I think work has continued on that 
project. That's an example of a project with the right scope. 

> 
> > 3) Accelerator node project. Some storage solutions out there offer an
> > "accelerator node", which is, in short, a, extra node with a lot of RAM,
> > eventually fast disks (SSD), and that works like a proxy to the regular
> > volumes. active chunks of files are moved there, logs (ZIL style) are
> > recorded on fast media, among other things. There is NO active project for
> > this, or trello entry, because it is something I started discussing with a
> > few fellows just a couple of days ago. I thought of starting to play with
> > RAM disks (tmpfs) as scratch disks, but, since we have an opportunity to do
> > something more efficient, or at the very least start it, why not ?
> 
> Looks like somebody has read the Isilon marketing materials.  ;)
> 
> A full production-level implementation of this, with cache consistency and
> so on, would be a major project.  However, a non-consistent prototype good
> for specific use cases - especially Hadoop, as Jay mentions - would be
> pretty easy to build.  Having a GlusterFS server (for the real clients)
> also be a GlusterFS client (to the real cluster) is pretty straightforward.
> Testing performance would also be a significant component of this, and IMO
> that's something more developers should learn about early in their careers.
> I encourage you to keep thinking about how this could be turned into a real
> GSoC proposal.

Excellent. This has possibilities. 

Another possibility is in the mobile app space. I think it would be awesome to 
port GFAPI to Android, for example. Or to make use of the python or ruby 
bindings for GFAPI to create a server-side RESTful API that a mobile app can 
access. 

-JM






reply via email to

[Prev in Thread] Current Thread [Next in Thread]