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@xxxxxxxxxx> wrote:
On 03/25/2013 10:53 AM, Vidar Hokstad wrote:Completely agree.
> as long as the
> chosen option doesn't make day to day troubleshooting and maintenance
> much harder...
That's what we do now. It does basically work at small scale, and we'd
> 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.
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@xxxxxxxxxx
https://lists.nongnu.org/mailman/listinfo/gluster-devel
