After reading through this thread, I feel compelled to make some comments.
I'm a user.
On Fri, Mar 22, 2013 at 2:09 PM, Jeff Darcy jda...@redhat.com wrote:
During the Bangalore architects' summit a couple of weeks ago, there
was a discussion about making most functions of glusterd into
Please review and comment.
Original Message
Subject: Change in glusterfs[master]: config: better (i.e. more portable) test
for libxml2
From: Kaleb KEITHLEY (Code Review) r...@dev.gluster.com
To:
CC:
Kaleb KEITHLEY has uploaded a new change for review.
Change subject:
On 03/25/2013 05:38 AM, Vidar Hokstad wrote:
I see a number of complaints about this as some sort of admission of
failure.
I wouldn't quite characterize it as failure. It does work, after all.
However, glusterd has kind of reached its limits. Moving it forward has
become increasingly
On Mon, Mar 25, 2013 at 1:07 PM, Jeff Darcy jda...@redhat.com wrote:
I'm a little surprised by the positive reactions to the Gluster on
Gluster approach. Even though Kaleb and I considered it for HekaFS,
it's still a bit of a hack. In particular, we'd still have to solve the
problems of
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
On 03/25/2013 12:44 PM, Alex Attarian wrote:
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
On 03/25/2013 02:24 PM, John Mark Walker wrote:
I would also point out that, as the community lead, I would very much
welcome alternative solutions to be played out on gluster.org
I don't think they'll be successful, but what do I know. I just want to
make it clear that alternative solutions
All and all what I'm asking is to find a way to keep the simplicity, not
just maintaining things, but having an overview of things. So when
something breaks no one has to go through multiple services to figure out
where the problem is.
We all know why gluster was such a success, simple and easy to
On Sun, Mar 24, 2013 at 8:57 PM, Justin Clift jcl...@redhat.com wrote:
On 23/03/2013, at 11:58 PM, Anand Babu Periasamy wrote:
snip
(4) Auto-generated volume spec is too limiting. There are other useful
translators, but not even included (but disabled) by default. Volume
spec file does not
On Mon, Mar 25, 2013 at 11:24 AM, John Mark Walker johnm...@redhat.com wrote:
- Original Message -
On 03/25/2013 12:44 PM, Alex Attarian wrote:
If you disagree with the very idea of having glusterd, then *we have
nothing to
talk about*. If you appreciate the infrastructure it
On Mon, Mar 25, 2013 at 6:07 AM, Jeff Darcy jda...@redhat.com wrote:
On 03/25/2013 05:38 AM, Vidar Hokstad wrote:
I see a number of complaints about this as some sort of admission of
failure.
I wouldn't quite characterize it as failure. It does work, after all.
However, glusterd has kind of
On Sun, Mar 24, 2013 at 9:04 PM, Justin Clift jcl...@redhat.com wrote:
On 24/03/2013, at 8:55 AM, Stephan von Krawczynski wrote:
snip
... the most
important question: the performance tuning. We all know that glusterfs can be
unbelievably slow if you tuned the wrong switches. And really,
Quick Update:
Ability to create GLUSTERFS_DOMAIN from oVirt web UI is now upstream.
http://gerrit.ovirt.org/#/c/8834/
http://gerrit.ovirt.org/#/c/8983/
http://gerrit.ovirt.org/#/c/13176/
This provides the capability to create a new DC, cluster of type
GLUSTERFS, ability to add new host to
13 matches
Mail list logo
