[Gluster-devel] Glusterd: A New Hope

[Alex Attarian]

I want to chime in as a regular user, since the 2.x days. Do you know why
people actually picked gluster, even when it was in really buggy state back
then? Simplicity! It was so much easier to maintain than anything else out
there, not even considering the small amount of components involved. You
had a good overview of the entire system and didn't have to scratch your
head when something failed.

Adding more complexity means only making it a nightmare for administrators.
I've said this times and times and I will say it again, your documentation
has always been bad, out of respect I'm not calling it shit. If you had
taken your time and grabbed a random admin and watched him set up a system,
you would've cried for him. Until this day I don't understand why you
haven't taken the time to sit down and write a good documentation so more
people can use gluster. Instead what happens is people come look at the
site, look at the docs and examples, and run away.

So from what I'm understanding here, you guys are trying to create even
more of a black box, kind of like NetApp or EMC, thus making it a nightmare
for admins. This only means they will either not recommend the solution
anymore or ask the higher ups to throw money at Red Hat, so you guys can
maintain it for them because they don't want to touch it. Is this how Red
Hat is trying to monetize Gluster now? Is there no other way to find a
solution where you guys can make money and still keep the software from
becoming bloatware?

I guess what I'm seeing now is you guys are opening up a huge niche for
someone else to step in and create a new gluster system just for the
purposes average companies need. While Red Hat gluster will go the route of
supporting users that have the need for those few complex features that you
are talking about.




On Mon, Mar 25, 2013 at 8:25 AM, Jeff Darcy <jdarcy at redhat.com> wrote:

> On 03/25/2013 10:53 AM, Vidar Hokstad wrote:
> > as long as the
> > chosen option doesn't make day to day troubleshooting and maintenance
> > much harder...
>
> Completely agree.
>
> > For a large deployment I agree you _need_ to
> > know those kind of things, but for a small one I'd be inclined to just
> > make every node hold the configuration data.
>
> That's what we do now.  It does basically work at small scale, and we'd
> like to preserve its simplicity whenever we can.  At larger scale, as
> you point out, administrators will have to be a little more aware of the
> coordination role and manage coordinator locations a little more
> carefully to reduce communication cost and the corresponding potential
> for partial success of an update (which could leave configs out of sync).
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130325/66d1aa66/attachment-0001.html>