<div dir="ltr">has the 32 group limit been fixed yet? If not how about that :) ? <a href="https://bugzilla.redhat.com/show_bug.cgi?id=789961">https://bugzilla.redhat.com/show_bug.cgi?id=789961</a></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 8:01 AM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">> I am a little bit impressed by the lack of action on this topic. I hate to be<br>
> "that guy", specially being new here, but it has to be done.<br>
> If I've got this right, we have here a chance of developing Gluster even<br>
> further, sponsored by Google, with a dedicated programmer for the summer.<br>
> In other words, if we play our cards right, we can get a free programmer and<br>
> at least a good start/advance on this fantastic.<br>
<br>
</div>Welcome, Carlos. I think it's great that you're taking initiative here.<br>
However, it's also important to set proper expectations for what a GSoC intern<br>
could reasonably be expected to achieve. I've seen some amazing stuff out of<br>
GSoC, but if we set the bar too high then we end up with incomplete code and<br>
the student doesn't learn much except frustration.<br>
<br>
GlusterFS consists of 430K lines of code in the core project alone. Most of<br>
it's written in a style that is generally hard for newcomers to pick up -<br>
both callback-oriented and highly concurrent, often using our own "unique"<br>
interpretation of standard concepts. It's also in an area (storage) that is<br>
not well taught in most universities. Given those facts and the short<br>
duration of GSoC, it's important to focus on projects that don't require deep<br>
knowledge of existing code, to keep the learning curve short and productive<br>
time correspondingly high. With that in mind, let's look at some of your<br>
suggestions.<br>
<div class=""><br>
> I think it would be nice to listen to the COMMUNITY (yes, that means YOU),<br>
> for either suggestions, or at least a vote.<br>
<br>
</div>It certainly would have been nice to have you at the community IRC meeting<br>
yesterday, at which we discussed release content for 3.6 based on the<br>
feature proposals here:<br>
<br>
<a href="http://www.gluster.org/community/documentation/index.php/Planning36" target="_blank">http://www.gluster.org/community/documentation/index.php/Planning36</a><br>
<br>
The results are here:<br>
<br>
<a href="http://titanpad.com/glusterfs-3-6-planning" target="_blank">http://titanpad.com/glusterfs-3-6-planning</a><br>
<div class=""><br>
> My opinion, being also my vote, in order of PERSONAL preference:<br>
</div>> 1) There is a project going on ( <a href="https://forge.gluster.org/disperse" target="_blank">https://forge.gluster.org/disperse</a> ), that<br>
<div class="">> consists on re-writing the stripe module on gluster. This is specially<br>
> important because it has a HUGE impact on Total Cost of Implementation<br>
> (customer side), Total Cost of Ownership, and also matching what the<br>
> competition has to offer. Among other things, it would allow gluster to<br>
> implement a RAIDZ/RAID5 type of fault tolerance, much more efficient, and<br>
> would, as far as I understand, allow you to use 3 nodes as a minimum<br>
> stripe+replication. This means 25% less money in computer hardware, with<br>
> increased data safety/resilience.<br>
<br>
</div>This was decided as a core feature for 3.6. I'll let Xavier (the feature<br>
owner) answer w.r.t. whether there's any part of it that would be<br>
appropriate for GSoC.<br>
<div class=""><br>
> 2) We have a recurring issue with split-brain solution. There is an entry on<br>
> trello asking/suggesting a mechanism that arbitrates this resolution<br>
> automatically. I pretty much think this could come together with another<br>
> solution that is file replication consistency check.<br>
<br>
</div>This is also core for 3.6 under the name "policy based split brain<br>
resolution":<br>
<br>
<a href="http://www.gluster.org/community/documentation/index.php/Features/pbspbr" target="_blank">http://www.gluster.org/community/documentation/index.php/Features/pbspbr</a><br>
<br>
Implementing this feature requires significant knowledge of AFR, which both<br>
causes split brain and would be involved in its repair. Because it's also<br>
one of our most complicated components, and the person who just rewrote it<br>
won't be around to offer help, I don't think this project *as a whole*<br>
would be a good fit for GSoC. On the other hand, there might be specific<br>
pieces of the policy implementation (not execution) that would be a good<br>
fit.<br>
<div class=""><br>
> 3) Accelerator node project. Some storage solutions out there offer an<br>
> "accelerator node", which is, in short, a, extra node with a lot of RAM,<br>
> eventually fast disks (SSD), and that works like a proxy to the regular<br>
> volumes. active chunks of files are moved there, logs (ZIL style) are<br>
> recorded on fast media, among other things. There is NO active project for<br>
> this, or trello entry, because it is something I started discussing with a<br>
> few fellows just a couple of days ago. I thought of starting to play with<br>
> RAM disks (tmpfs) as scratch disks, but, since we have an opportunity to do<br>
> something more efficient, or at the very least start it, why not ?<br>
<br>
</div>Looks like somebody has read the Isilon marketing materials. ;)<br>
<br>
A full production-level implementation of this, with cache consistency and<br>
so on, would be a major project. However, a non-consistent prototype good<br>
for specific use cases - especially Hadoop, as Jay mentions - would be<br>
pretty easy to build. Having a GlusterFS server (for the real clients)<br>
also be a GlusterFS client (to the real cluster) is pretty straightforward.<br>
Testing performance would also be a significant component of this, and IMO<br>
that's something more developers should learn about early in their careers.<br>
I encourage you to keep thinking about how this could be turned into a real<br>
GSoC proposal.<br>
<br>
<br>
Keep the ideas coming!<br>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br>
</blockquote></div><br></div>