----- 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 _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users