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: Lalatendu Mohanty
Subject: Re: [Gluster-devel] [Gluster-users] PLEASE READ ! We need your opinion. GSOC-2014 and the Gluster community
Date: Tue, 18 Mar 2014 09:07:30 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

On 03/13/2014 11:49 PM, John Mark Walker wrote:
----- 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.

IMO integration projects are ideal fits for GSoc. I can see some information in Trello back log i.e. under "Ecosystem Integration". But not sure of their current status. I think we should again take look on these and see if something can be done through GSoc.

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



_______________________________________________
Gluster-users mailing list
address@hidden
http://supercolony.gluster.org/mailman/listinfo/gluster-users




reply via email to

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