On Mon, 27 Aug 2012 18:43:27 +0100
Brian Candler b.cand...@pobox.com wrote:
On Mon, Aug 27, 2012 at 03:08:21PM +0200, Stephan von Krawczynski wrote:
The gluster version is 2.X and cannot be changed.
Ah, that's the important bit. If you have a way to replicate the problem
with current code
On Tue, Aug 28, 2012 at 10:01:16AM +0200, Stephan von Krawczynski wrote:
Again, let me note two things:
- the current code has a lot more (other) problems than the 2.X tree, that is
why we won't use that.
- if one has to look at the code to find out the basic problem he is not the
target
On Tue, 28 Aug 2012 09:21:57 +0100
Brian Candler b.cand...@pobox.com wrote:
On Tue, Aug 28, 2012 at 10:01:16AM +0200, Stephan von Krawczynski wrote:
Again, let me note two things:
- the current code has a lot more (other) problems than the 2.X tree, that
is
why we won't use that.
- if
Thanks for sharing it with us Bharata.
I saw you have two nodes. Have you done any performance tests and if so how
they compare with creating normal .qcow2 or .raw files on the filesystem,
specially for the writes ?
Thanks
Fernando
-Original Message-
From:
* s19n mail...@s19n.net [2012 08 27, 17:56]:
Additional update: seems that the command (and many others) is not
working because of a 'local lock' being held.
I think I am hitting the following, so I'll be looking forward the fix:
https://bugzilla.redhat.com/show_bug.cgi?id=843003
Hi,
Wanted to check if any one is using gluster CLI output of 'peer status'
in their scripts/programs? If yes, let me know. If not, we are trying to
make it more script friendly.
For example the current output would look something like:
-
Hostname: 10.70.36.7
Uuid:
Glusterd holds a cluster wide lock before performing any volume
operation requested by cli (excluding 'volume info'). This lock is
supposed to be released at the end of the given operation, whether the
operation succeeded or not, but it appears that it hasn't in your
case. But I don't think you've
htmlbodyI would love thisand would be more than happy to change my
current parsing...this would make it A LOT easier to parseas well as easier
to see all information on a disconnected peer as the information will be in a
single line.
Bryan Washer
-Original Message-
From:
hi Amar,
This is the format we considered initially but we did not go with this
because it may exceed 80 chars and wrap over for small terminals if we want to
add more fields in future.
Pranith.
- Original Message -
From: Amar Tumballi ama...@redhat.com
To: Gluster Devel
Bryan,
Why not use --xml at the end of the command? That will print the output in
xml format. Would that make it easy to parse?.
Pranith.
- Original Message -
From: Bryan Washer bwas...@netsuite.com
To: Amar Tumballi ama...@redhat.com, Gluster Devel
gluster-de...@nongnu.org,
On Tue, Aug 28, 2012 at 9:46 AM, Pranith Kumar Karampuri
pkara...@redhat.com wrote:
hi Amar,
This is the format we considered initially but we did not go with
this because it may exceed 80 chars and wrap over for small terminals if we
want to add more fields in future.
It would be
htmlbodyIf this is the case...why not add a flag for the more verbose
information ...and let the default provide just the basics with output very
easy to parse like this...
Bryan Washer
-Original Message-
From: gluster-users-boun...@gluster.org
htmlbodyPranith,
I will look at it...Thanks.
Bryan
-Original Message-
From: Pranith Kumar Karampuri [mailto:pkara...@redhat.com]
Sent: Tuesday, August 28, 2012 7:51 AM
To: Washer, Bryan
Cc: Amar Tumballi; Gluster Devel; gluster-users
Subject: Re: [Gluster-users] FeedBack Requested :
Top posting and kidding is a bit exaggerated for one posting ...
You are not seriously talking about 80 char terminals for an output that is
commonly used by scripts and stuff like nagios, are you?
On Tue, 28 Aug 2012 08:46:22 -0400 (EDT)
Pranith Kumar Karampuri pkara...@redhat.com wrote:
hi
No. Output formats in that way generally start out nice but as you start adding
more fields, formatting them becomes difficult IMO.
Pranith
- Original Message -
From: Stephan von Krawczynski sk...@ithnet.com
To: Pranith Kumar Karampuri pkara...@redhat.com
Cc: gluster-users
* Stephan von Krawczynski sk...@ithnet.com [2012 08 28, 15:31]:
You are not seriously talking about 80 char terminals for an output
that is commonly used by scripts and stuff like nagios, are you?
-
Hostname: 10.70.36.7
Uuid: c7283ee7-0e8d-4cb8-8552-a63ab05deaa7
State: Peer in
Bryan,
FYI XML output for 'peer status' isn't yet present in 3.3.0. It was
just pushed into master. So if you want to test it, you'll have to
build from master
- Kaushal
On Tue, Aug 28, 2012 at 7:27 PM, Pranith Kumar Karampuri
pkara...@redhat.com wrote:
No. Output formats in that way generally
On Tue, 2012-08-28 at 08:46 -0400, Pranith Kumar Karampuri wrote:
hi Amar,
This is the format we considered initially but we did not go with this
because it may exceed 80 chars and wrap over for small terminals if we want
to add more fields in future.
This actually seems like a fairly
Brian
thanks for this response.
Since we are on the subject of hardware what would be the perfect fit
for a gluster brick. We where looking at a PowerEdge C2100 Rack Server.
During testing I found it pretty easy to saturate 1 Gig network links.
This was also the case when multiple links
On Tue, Aug 28, 2012 at 10:29:55AM -0500, Matt Weil wrote:
Since we are on the subject of hardware what would be the perfect
fit for a gluster brick. We where looking at a PowerEdge C2100 Rack
Server.
Looks fine to me; UK website doesn't give the pricing so I imagine it's
pretty expensive :-)
I was able to cause client crashes with the 3.5 kernels in Fedora and have
opened a bug report.
Bugzilla is down right now or I would give you the bug link.
Yannik Lieblinger yan...@lieblinger.de wrote:
Hi Joe,
I have do an update to the new kernel 3.5.2-3.fc17.x86_64. And have the same
Hi Pranith,
On Tue, Aug 28, 2012 at 6:51 AM, Pranith Kumar Karampuri
pkara...@redhat.com wrote:
Why not use --xml at the end of the command? That will print the output
in xml format. Would that make it easy to parse?.
IMO, I can see --xml being useful for more sophisticated scripts that
On Tue, 2012-08-28 at 12:51 -0600, Joe Topjian wrote:
Hi Pranith,
On Tue, Aug 28, 2012 at 6:51 AM, Pranith Kumar Karampuri
pkara...@redhat.com wrote:
Why not use --xml at the end of the command? That will
print the output in xml format. Would that make it easy to
Hi James,
FWIW: I tend to agree on this point. The other question that comes to
mind is what quick bash scripts are you writing for managing gluster?
quick might not have been the best word to use -- maybe small would
have been better.
For example, peer status + columns + grep + awk could be
On Tue, 2012-08-28 at 13:02 -0600, Joe Topjian wrote:
Hi James,
FWIW: I tend to agree on this point. The other question that
comes to
mind is what quick bash scripts are you writing for managing
gluster?
quick might not have been the best word to use --
I'd just like to also state this is fantastic. I hope the performance
will match.
On Tue, Aug 28, 2012 at 2:34 AM, Fernando Frediani (Qube)
fernando.fredi...@qubenet.net wrote:
Thanks for sharing it with us Bharata.
I saw you have two nodes. Have you done any performance tests and if so how
Ok, maybe I didn't explain the true nature in detail:
The number of fields and the formatting is all the same. nobody wants to read
the output. Instead it is read by scripts most of the time. so the only valid
question is the field delimiter, simply to make the output parseable as easy
as possible
On Tue, Aug 28, 2012 at 4:06 AM, Amar Tumballi ama...@redhat.com wrote:
Hi,
Wanted to check if any one is using gluster CLI output of 'peer status' in
their scripts/programs? If yes, let me know. If not, we are trying to make
it more script friendly.
For example the current output would
28 matches
Mail list logo
