Re: [Gluster-users] Gluster replicate 3 arbiter 1 in split brain. gluster cli seems unaware

[Karthik Subrahmanya]

Hi Henrik,

Thanks for providing the required outputs. See my replies inline.

On Thu, Dec 21, 2017 at 10:42 PM, Henrik Juul Pedersen  wrote:

> Hi Karthik and Ben,
>
> I'll try and reply to you inline.
>
> On 21 December 2017 at 07:18, Karthik Subrahmanya 
> wrote:
> > Hey,
> >
> > Can you give us the volume info output for this volume?
>
> # gluster volume info virt_images
>
> Volume Name: virt_images
> Type: Replicate
> Volume ID: 9f3c8273-4d9d-4af2-a4e7-4cb4a51e3594
> Status: Started
> Snapshot Count: 2
> Number of Bricks: 1 x (2 + 1) = 3
> Transport-type: tcp
> Bricks:
> Brick1: virt3:/data/virt_images/brick
> Brick2: virt2:/data/virt_images/brick
> Brick3: printserver:/data/virt_images/brick (arbiter)
> Options Reconfigured:
> features.quota-deem-statfs: on
> features.inode-quota: on
> features.quota: on
> features.barrier: disable
> features.scrub: Active
> features.bitrot: on
> nfs.rpc-auth-allow: on
> server.allow-insecure: on
> user.cifs: off
> features.shard: off
> cluster.shd-wait-qlength: 1
> cluster.locking-scheme: granular
> cluster.data-self-heal-algorithm: full
> cluster.server-quorum-type: server
> cluster.quorum-type: auto
> cluster.eager-lock: enable
> network.remote-dio: enable
> performance.low-prio-threads: 32
> performance.io-cache: off
> performance.read-ahead: off
> performance.quick-read: off
> nfs.disable: on
> transport.address-family: inet
> server.outstanding-rpc-limit: 512
>
> > Why are you not able to get the xattrs from arbiter brick? It is the same
> > way as you do it on data bricks.
>
> Yes I must have confused myself yesterday somehow, here it is in full
> from all three bricks:
>
> Brick 1 (virt2): # getfattr -d -m . -e hex fedora27.qcow2
> # file: fedora27.qcow2
> trusted.afr.dirty=0x
> trusted.afr.virt_images-client-1=0x0228
> trusted.afr.virt_images-client-3=0x
> trusted.bit-rot.version=0x1d005a3aa0db000c6563
> trusted.gfid=0x7a36937d52fc4b55a93299e2328f02ba
> trusted.gfid2path.c076c6ac27a43012=0x30303030303030302d303030302d
> 303030302d303030302d3030303030303030303030312f6665646f726132372e71636f7732
> trusted.glusterfs.quota.----0001.contri.1=
> 0xa49eb001
> trusted.pgfid.----0001=0x0001
>
> Brick 2 (virt3): # getfattr -d -m . -e hex fedora27.qcow2
> # file: fedora27.qcow2
> trusted.afr.dirty=0x
> trusted.afr.virt_images-client-2=0x03ef
> trusted.afr.virt_images-client-3=0x
> trusted.bit-rot.version=0x19005a3a9f82000c382a
> trusted.gfid=0x7a36937d52fc4b55a93299e2328f02ba
> trusted.gfid2path.c076c6ac27a43012=0x30303030303030302d303030302d
> 303030302d303030302d3030303030303030303030312f6665646f726132372e71636f7732
> trusted.glusterfs.quota.----0001.contri.1=
> 0xa2fbe001
> trusted.pgfid.----0001=0x0001
>
> Brick 3 - arbiter (printserver): # getfattr -d -m . -e hex fedora27.qcow2
> # file: fedora27.qcow2
> trusted.afr.dirty=0x
> trusted.afr.virt_images-client-1=0x0228
> trusted.bit-rot.version=0x31005a39237200073206
> trusted.gfid=0x7a36937d52fc4b55a93299e2328f02ba
> trusted.gfid2path.c076c6ac27a43012=0x30303030303030302d303030302d
> 303030302d303030302d3030303030303030303030312f6665646f726132372e71636f7732
> trusted.glusterfs.quota.----0001.contri.1=
> 0x0001
> trusted.pgfid.----0001=0x0001
>
> I was expecting trusted.afr.virt_images-client-{1,2,3} on all bricks?
>
>From AFR-V2 we do not have  self blaming attrs. So you will see a brick
blaming other bricks only.
For example brcik1 can blame brick2 & brick 3, not itself.

>
> > The changelog xattrs are named trusted.afr.virt_images-client-{1,2,3}
> in the
> > getxattr outputs you have provided.
> > Did you do a remove-brick and add-brick any time? Otherwise it will be
> > trusted.afr.virt_images-client-{0,1,2} usually.
>
> Yes, the bricks was moved around initially; brick 0 was re-created as
> brick 2, and the arbiter was added later on as well.
>
> >
> > To overcome this scenario you can do what Ben Turner had suggested.
> Select
> > the source copy and change the xattrs manually.
>
> I won't mind doing that, but again, the guides assume that I have
> trusted.afr.virt_images-client-{1,2,3} on all bricks, so I'm not sure
> what to change to what, where.


> > I am suspecting that it has hit the arbiter becoming source for data heal
> > bug. But to confirm that we need the xattrs on the arbiter brick also.
> >
> > Regards,
> > Karthik
> >
> >
> > On Thu, Dec 21, 2017 at 9:55 AM, Ben Turner  wrote:
> >>
> >> Here is the process for resolving split brain on replica 2:
> >>
> >>
> >> 

[Gluster-users] Announcing Glusterfs release 3.13.1 (Short Term Maintenance)

[Jiffin Tony Thottan]

The Gluster community is pleased to announce the release of Gluster 
3.13.1 (packages available at [1,2,3]).


Release notes for the release can be found at [4].

We still carry following major issue that is reported in the 
release-notes as follows,


1.) - Expanding a gluster volume that is sharded may cause file corruption

    Sharded volumes are typically used for VM images, if such volumes 
are expanded or possibly contracted (i.e add/remove bricks and 
rebalance) there are reports of VM images getting corrupted.


    The last known cause for corruption (Bug #1515434) has a fix with 
this release. As further testing is still in progress, the issue is 
retained as a major issue.


    Status of this bug can be tracked here, #1515434

Thanks,
Gluster community


[1] https://download.gluster.org/pub/gluster/glusterfs/3.13/3.13.1/
[2] https://launchpad.net/~gluster/+archive/ubuntu/glusterfs-3.13
[3] https://build.opensuse.org/project/subprojects/home:glusterfs
[4] Release notes: 
https://gluster.readthedocs.io/en/latest/release-notes/3.13.1/


___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] Syntax for creating arbiter volumes in gluster 4.0

[Ravishankar N]

Thanks wk, Jim and Shyam for the feedback.  Let us go with `replica 2 
arbiter 1` in that case.


@Shyam, There are no plans to make arbiter count more than 1, but I 
think it is better to have it stated explicitly. If we are not going 
with a new volume type but  say `replica 2 arbiter` and give 3 brick 
paths, it can be confusing, so sticking to `replica 2 arbiter 1 for now.


Regards,
Ravi

On 12/20/2017 03:44 PM, Ravishankar N wrote:

Hi,

The existing syntax in the gluster CLI for creating arbiter volumes is 
`gluster volume create  replica 3 arbiter 1 ` 
. It means (or at least intended to mean) that out of the 3 bricks, 1 
brick is the arbiter.
There has been some feedback while implementing arbiter support in 
glusterd2 for glusterfs-4.0 that we should change this to `replica 2 
arbiter 1` , meaning that there are 2 replica (data) bricks and the 
3rd one is the arbiter (which only holds meta data).


See [1] for some discussions. What does everyone feel is more user 
friendly and intuitive?


Thanks,
Ravi

[1] https://github.com/gluster/glusterd2/pull/480
___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users


___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] seeding my georeplication

[Stephen Remde]

Thanks for your response (6 months ago!) but I have only just got around to
following up on this.

Unfortunately, I had already copied and shipped the data to the second
datacenter before copying the GFIDs so I already stumbled before the first
hurdle!

I have been using the scripts in the extras/geo-rep provided for an earlier
version upgrade. With a bit of tinkering, these have given me a file
contianing the gfid/file pairs needed to sync to the slave before enabling
georeplication.

Unfortunately, the gsync-sync-gfid program isn't working. On all the files
it reports that they failed and I see the following in the fuse log:

[2017-12-21 16:36:37.171846] D [MSGID: 0]
[dht-common.c:997:dht_revalidate_cbk] 0-video-backup-dht: revalidate
lookup of /path returned with op_ret 0 [Invalid argument]
[2017-12-21 16:36:37.172352] D
[fuse-helpers.c:650:fuse_ignore_xattr_set] 0-glusterfs-fuse: allowing
setxattr: key [glusterfs.gfid.heal],  client pid [0]
[2017-12-21 16:36:37.172457] D [logging.c:1953:_gf_msg_internal]
0-logging-infra: Buffer overflow of a buffer whose size limit is 5.
About to flush least recently used log message to disk
The message "D [MSGID: 0] [dht-common.c:997:dht_revalidate_cbk]
0-video-backup-dht: revalidate lookup of /path returned with op_ret 0
[Invalid argument]" repeated 8 times between [2017-12-21
16:36:37.171846] and [2017-12-21 16:36:37.172225]
[2017-12-21 16:36:37.172457] D [MSGID: 0]
[dht-common.c:2692:dht_lookup] 0-video-backup-dht: Calling fresh
lookup for /path/file.txt on video-backup-client-4
[2017-12-21 16:36:37.173166] D [MSGID: 0]
[client-rpc-fops.c:2910:client3_3_lookup_cbk] 0-video-backup-client-4:
gfid changed for /path/file.txt
[2017-12-21 16:36:37.173212] D [MSGID: 0]
[client-rpc-fops.c:2941:client3_3_lookup_cbk] 0-stack-trace:
stack-address: 0x7fe39ebdc42c, video-backup-client-4 returned -1
error: Stale file handle [Stale file handle]
[2017-12-21 16:36:37.173233] D [MSGID: 0]
[dht-common.c:2279:dht_lookup_cbk] 0-video-backup-dht: fresh_lookup
returned for /path/file.txt with op_ret -1 [Stale file handle]
[2017-12-21 16:36:37.173250] D [MSGID: 0]
[dht-common.c:2359:dht_lookup_cbk] 0-video-backup-dht: Lookup of
/path/file.txt for subvolume video-backup-client-4 failed [Stale file
handle]
[2017-12-21 16:36:37.173267] D [MSGID: 0]
[dht-common.c:2422:dht_lookup_cbk] 0-stack-trace: stack-address:
0x7fe39ebdc42c, video-backup-dht returned -1 error: Stale file handle
[Stale file handle]
[2017-12-21 16:36:37.173285] D [MSGID: 0]
[io-cache.c:256:ioc_lookup_cbk] 0-stack-trace: stack-address:
0x7fe39ebdc42c, video-backup-io-cache returned -1 error: Stale file
handle [Stale file handle]
[2017-12-21 16:36:37.173303] D [MSGID: 0]
[quick-read.c:447:qr_lookup_cbk] 0-stack-trace: stack-address:
0x7fe39ebdc42c, video-backup-quick-read returned -1 error: Stale file
handle [Stale file handle]
[2017-12-21 16:36:37.173320] D [MSGID: 0]
[md-cache.c:863:mdc_lookup_cbk] 0-stack-trace: stack-address:
0x7fe39ebdc42c, video-backup-md-cache returned -1 error: Stale file
handle [Stale file handle]
[2017-12-21 16:36:37.173336] D [MSGID: 0]
[io-stats.c:2116:io_stats_lookup_cbk] 0-stack-trace: stack-address:
0x7fe39ebdc42c, video-backup returned -1 error: Stale file handle
[Stale file handle]
[2017-12-21 16:36:37.173374] D [MSGID: 0]
[gfid-access.c:390:ga_heal_cbk] 0-stack-trace: stack-address:
0x7fe39ebd7498, gfid-access-autoload returned -1 error: Stale file
handle [Stale file handle]
[2017-12-21 16:36:37.173405] W [fuse-bridge.c:1291:fuse_err_cbk]
0-glusterfs-fuse: 57862: SETXATTR() /path => -1 (Stale file handle)

I notice in slave-upgrade.sh, the .glusterfs contents on each brick
are deleted, and the volume restarted before gsync-sync-gfid is run.

I have a good working backup at the moment and deleting the .glusterfs
folder worries me. Is this the solution, or is something else wrong?








On 27 June 2017 at 06:31, Aravinda  wrote:

> Answers inline,
>
> @Kotresh, please add if I missed anything.
>
> regards
> Aravinda VKhttp://aravindavk.in
>
> On 06/23/2017 06:29 PM, Stephen Remde wrote:
>
> I have a ~600tb distributed gluster volume that I want to start using geo
> replication on.
>
> The current volume is on 6 100tb bricks on 2 servers
>
> My plan is:
>
> 1) copy each of the bricks to a new arrays on the servers locally
>
> Before start copying,
> - Enable changelog in Master volume, using `gluster volume set 
> changelog.changelog on`
> - Record the Timestamp. This is required to set the marking once Geo-rep
> session is created.
> - Gluster Geo-replication replicates the data with same GFID in target, so
> if we are copying data manually we should ensure that GFIDs remains same
> and properly linked as hardlinks in the .glusterfs directory.
>
> 2) move the new arrays to the new servers
> 3) create the volume on the new servers using the arrays
> 4) fix the layout on the new volume
>
>
> 5) start georeplication (which should be relatively small as most of the
> data 

Re: [Gluster-users] Gluster replicate 3 arbiter 1 in split brain. gluster cli seems unaware

[Henrik Juul Pedersen]

Hi Karthik and Ben,

I'll try and reply to you inline.

On 21 December 2017 at 07:18, Karthik Subrahmanya  wrote:
> Hey,
>
> Can you give us the volume info output for this volume?

# gluster volume info virt_images

Volume Name: virt_images
Type: Replicate
Volume ID: 9f3c8273-4d9d-4af2-a4e7-4cb4a51e3594
Status: Started
Snapshot Count: 2
Number of Bricks: 1 x (2 + 1) = 3
Transport-type: tcp
Bricks:
Brick1: virt3:/data/virt_images/brick
Brick2: virt2:/data/virt_images/brick
Brick3: printserver:/data/virt_images/brick (arbiter)
Options Reconfigured:
features.quota-deem-statfs: on
features.inode-quota: on
features.quota: on
features.barrier: disable
features.scrub: Active
features.bitrot: on
nfs.rpc-auth-allow: on
server.allow-insecure: on
user.cifs: off
features.shard: off
cluster.shd-wait-qlength: 1
cluster.locking-scheme: granular
cluster.data-self-heal-algorithm: full
cluster.server-quorum-type: server
cluster.quorum-type: auto
cluster.eager-lock: enable
network.remote-dio: enable
performance.low-prio-threads: 32
performance.io-cache: off
performance.read-ahead: off
performance.quick-read: off
nfs.disable: on
transport.address-family: inet
server.outstanding-rpc-limit: 512

> Why are you not able to get the xattrs from arbiter brick? It is the same
> way as you do it on data bricks.

Yes I must have confused myself yesterday somehow, here it is in full
from all three bricks:

Brick 1 (virt2): # getfattr -d -m . -e hex fedora27.qcow2
# file: fedora27.qcow2
trusted.afr.dirty=0x
trusted.afr.virt_images-client-1=0x0228
trusted.afr.virt_images-client-3=0x
trusted.bit-rot.version=0x1d005a3aa0db000c6563
trusted.gfid=0x7a36937d52fc4b55a93299e2328f02ba
trusted.gfid2path.c076c6ac27a43012=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f6665646f726132372e71636f7732
trusted.glusterfs.quota.----0001.contri.1=0xa49eb001
trusted.pgfid.----0001=0x0001

Brick 2 (virt3): # getfattr -d -m . -e hex fedora27.qcow2
# file: fedora27.qcow2
trusted.afr.dirty=0x
trusted.afr.virt_images-client-2=0x03ef
trusted.afr.virt_images-client-3=0x
trusted.bit-rot.version=0x19005a3a9f82000c382a
trusted.gfid=0x7a36937d52fc4b55a93299e2328f02ba
trusted.gfid2path.c076c6ac27a43012=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f6665646f726132372e71636f7732
trusted.glusterfs.quota.----0001.contri.1=0xa2fbe001
trusted.pgfid.----0001=0x0001

Brick 3 - arbiter (printserver): # getfattr -d -m . -e hex fedora27.qcow2
# file: fedora27.qcow2
trusted.afr.dirty=0x
trusted.afr.virt_images-client-1=0x0228
trusted.bit-rot.version=0x31005a39237200073206
trusted.gfid=0x7a36937d52fc4b55a93299e2328f02ba
trusted.gfid2path.c076c6ac27a43012=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f6665646f726132372e71636f7732
trusted.glusterfs.quota.----0001.contri.1=0x0001
trusted.pgfid.----0001=0x0001

I was expecting trusted.afr.virt_images-client-{1,2,3} on all bricks?

> The changelog xattrs are named trusted.afr.virt_images-client-{1,2,3} in the
> getxattr outputs you have provided.
> Did you do a remove-brick and add-brick any time? Otherwise it will be
> trusted.afr.virt_images-client-{0,1,2} usually.

Yes, the bricks was moved around initially; brick 0 was re-created as
brick 2, and the arbiter was added later on as well.

>
> To overcome this scenario you can do what Ben Turner had suggested. Select
> the source copy and change the xattrs manually.

I won't mind doing that, but again, the guides assume that I have
trusted.afr.virt_images-client-{1,2,3} on all bricks, so I'm not sure
what to change to what, where.

> I am suspecting that it has hit the arbiter becoming source for data heal
> bug. But to confirm that we need the xattrs on the arbiter brick also.
>
> Regards,
> Karthik
>
>
> On Thu, Dec 21, 2017 at 9:55 AM, Ben Turner  wrote:
>>
>> Here is the process for resolving split brain on replica 2:
>>
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Storage/2.1/html/Administration_Guide/Recovering_from_File_Split-brain.html
>>
>> It should be pretty much the same for replica 3, you change the xattrs
>> with something like:
>>
>> # setfattr -n trusted.afr.vol-client-0 -v 0x0001
>> /gfs/brick-b/a
>>
>> When I try to decide which copy to use I normally run things like:
>>
>> # stat //pat/to/file
>>
>> Check out the access and change times of the file on the back end bricks.
>> I normally pick the copy with the latest access / change times.  

Re: [Gluster-users] Wrong volume size with df

[Ashish Pandey]

Could youplease provide following - 

1 - output of gluster volume heal  info 
2 - /var/log/glusterfs - provide log file with mountpoint-volumename.log 
3 - output of gluster volume  info 
4 - output of gluster volume  status 
5 - Also, could you try unmount the volume and mount it again and check the 
size? 







- Original Message -

From: "Teknologeek Teknologeek"  
To: gluster-users@gluster.org 
Sent: Wednesday, December 20, 2017 2:54:40 AM 
Subject: [Gluster-users] Wrong volume size with df 

I have a glusterfs setup with distributed disperse volumes 5 * ( 4 + 2 ). 

After a server crash, "gluster peer status" reports all peers as connected. 

"gluster volume status detail" shows that all bricks are up and running with 
the right size, but when I use df from a client mount point, the size displayed 
is about 1/6 of the total size. 

When browsing the data, they seem to be ok tho. 

I need some help to understand what's going on as i can't delete the volume and 
recreate it from scratch. 

___ 
Gluster-users mailing list 
Gluster-users@gluster.org 
http://lists.gluster.org/mailman/listinfo/gluster-users 

___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] Wrong volume size with df

[Tom Fite]

I'm seeing a similar issue. It appears that df on the client is reporting
the *brick* size instead of the total pool size. I think that this started
happening after one of my servers crashed due to a hardware issue.

I'm running a distributed / replicated volume, 2 boxes with 3 bricks each,
gluster 3.12.1

Thanks
-Tom

On Tue, Dec 19, 2017 at 4:24 PM, Teknologeek Teknologeek <
teknologee...@gmail.com> wrote:

> I have a glusterfs setup with distributed disperse volumes 5 * ( 4 + 2 ).
>
> After a server crash, "gluster peer status" reports all peers as connected.
>
> "gluster volume status detail" shows that all bricks are up and running
> with the right size, but when I use df from a client mount point, the size
> displayed is about 1/6 of the total size.
>
> When browsing the data, they seem to be ok tho.
>
> I need some help to understand what's going on as i can't delete the
> volume and recreate it from scratch.
>
> ___
> Gluster-users mailing list
> Gluster-users@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>
___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

[Gluster-users] stale file handle on gluster NFS client when trying to remove a directory

[Jeevan Patnaik]

Hi,


After running rm -rf on a directory, the files under it got deleted, but
the directory was not deleted and was showing stale file handle error.
After 18 minutes, I'm able to delete the directory. So could anyone help me
in knowing what could have happened or when in general I get such errors.


The following is NFS log:


[2017-12-21 13:56:01.592256] I [MSGID: 108019]
[afr-transaction.c:1903:afr_post_blocking_entrylk_cbk]
0-g_sitework2-replicate-5: Blocking entrylks failed.

[2017-12-21 13:56:01.594350] W [MSGID: 108019]
[afr-lk-common.c:1064:afr_log_entry_locks_failure]
0-g_sitework2-replicate-4: Unable to obtain sufficient blocking entry locks
on at least one child while attempting RMDIR on
{pgfid:23558c59-87e5-4e90-a610-8a47ec08b27c, name:csrc}.

[2017-12-21 13:56:01.594648] I [MSGID: 108019]
[afr-transaction.c:1903:afr_post_blocking_entrylk_cbk]
0-g_sitework2-replicate-4: Blocking entrylks failed.

[2017-12-21 13:56:01.594790] W [MSGID: 112032]
[nfs3.c:3713:nfs3svc_rmdir_cbk] 0-nfs: df521f4d:
/csrc => -1 (Stale file handle)
[Stale file handle]

[2017-12-21 13:56:01.594816] W [MSGID: 112199]
[nfs3-helpers.c:3414:nfs3_log_common_res] 0-nfs-nfsv3:
/csrc => (XID: df521f4d, RMDIR:
NFS: 70(Invalid file handle), POSIX: 116(Stale file handle))

[2017-12-21 13:56:01.590522] W [MSGID: 108019]
[afr-lk-common.c:1064:afr_log_entry_locks_failure]
0-g_sitework2-replicate-2: Unable to obtain sufficient blocking entry locks
on at least one child while attempting RMDIR on
{pgfid:23558c59-87e5-4e90-a610-8a47ec08b27c, name:csrc}.

[2017-12-21 13:56:01.590569] W [MSGID: 108019]
[afr-lk-common.c:1064:afr_log_entry_locks_failure]
0-g_sitework2-replicate-1: Unable to obtain sufficient blocking entry locks
on at least one child while attempting RMDIR on
{pgfid:23558c59-87e5-4e90-a610-8a47ec08b27c, name:csrc}.


Regards,

Jeevan.
___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] gluster and HA NFS

[Renaud Fortier]

Hi,
i'm also looking forward to get the answer.
Right now, we are using 3.10 with nfs-ganesha HA.

Thank you
Renaud

De : gluster-users-boun...@gluster.org 
[mailto:gluster-users-boun...@gluster.org] De la part de Tomalak Geret'kal
Envoyé : 20 décembre 2017 12:24
À : gluster-users@gluster.org
Objet : Re: [Gluster-users] gluster and HA NFS

On 20/12/2017 16:51, Craig Lesle wrote:
With the release of 3.12 ltm and now 3.13 stm, when 4.0 is released 3.10 is 
shown to be at eol;

Version Status  Release_Date  EOL_Version EOL_Date
3.10LTM 2017-02-274.0
3.11EOL 2017-05-303.122017-8-30
3.12LTM 2017-08-304.3
3.13STM 2017-12-7 4.0
4.0 Planned STM about 2018-01 4.1
4.1 Planned LTM about 2018-04 n+

What approach should a gluster consumer use today in setting up ha nfs on 
gluster? Is it still being recommended to use 3.10 with it's eol coming in what 
looks to be a matter of days/weeks? Perhaps the 3.10 support period will be 
extended for a reasonable amount of time until such time as storhaus in the 4 
tree is ready to go and some kind of workable upgrade path is ready to get the 
HA portion upgraded from 3.10 to 4.x ? Since storhaug appears to be a sticking 
point for moving forward beyond 3.10 in the v3 tree, is it possible to bring 
nfs-ganesha back for ha use at least through the v3 tree or are all eyes on v4 
and not looking back?
This is a good question and I'm also curious to learn the answer. More 
generally, going from release to EOL in just three months seems absolutely 
crazy to me, particularly as this project is owned by Red Hat who purport to 
maintain enterprise-grade support lifetimes. We should be talking about years, 
not months. As things stand today, I can't even deploy a new version before 
it's already EOL.

Cheers
___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] glusterfs, ganesh, and pcs rules

[Renaud Fortier]

Hi,
In your ganesha-ha.conf do you have your virtual ip adresses set something like 
this : 

VIP_tlxdmz-nfs1="192.168.22.33" 
VIP_tlxdmz-nfs2="192.168.22.34"

Renaud

De : gluster-users-boun...@gluster.org 
[mailto:gluster-users-boun...@gluster.org] De la part de Hetz Ben Hamo
Envoyé : 20 décembre 2017 04:35
À : gluster-users@gluster.org
Objet : [Gluster-users] glusterfs, ganesh, and pcs rules

Hi,

I've just created again the gluster with NFS ganesha. Glusterfs version 3.8

When I run the command  gluster nfs-ganesha enable - it returns a success. 
However, looking at the pcs status, I see this:

[root@tlxdmz-nfs1 ~]# pcs status
Cluster name: ganesha-nfs
Stack: corosync
Current DC: tlxdmz-nfs2 (version 1.1.16-12.el7_4.5-94ff4df) - partition with 
quorum
Last updated: Wed Dec 20 09:20:44 2017
Last change: Wed Dec 20 09:19:27 2017 by root via cibadmin on tlxdmz-nfs1

2 nodes configured
8 resources configured

Online: [ tlxdmz-nfs1 tlxdmz-nfs2 ]

Full list of resources:

 Clone Set: nfs_setup-clone [nfs_setup]
     Started: [ tlxdmz-nfs1 tlxdmz-nfs2 ]
 Clone Set: nfs-mon-clone [nfs-mon]
     Started: [ tlxdmz-nfs1 tlxdmz-nfs2 ]
 Clone Set: nfs-grace-clone [nfs-grace]
     Started: [ tlxdmz-nfs1 tlxdmz-nfs2 ]
 tlxdmz-nfs1-cluster_ip-1       (ocf::heartbeat:IPaddr):        Stopped
 tlxdmz-nfs2-cluster_ip-1       (ocf::heartbeat:IPaddr):        Stopped

Failed Actions:
* tlxdmz-nfs1-cluster_ip-1_monitor_0 on tlxdmz-nfs2 'not configured' (6): 
call=23, status=complete, exitreason='IP address (the ip parameter) is 
mandatory',
    last-rc-change='Wed Dec 20 09:19:28 2017', queued=0ms, exec=26ms
* tlxdmz-nfs2-cluster_ip-1_monitor_0 on tlxdmz-nfs2 'not configured' (6): 
call=27, status=complete, exitreason='IP address (the ip parameter) is 
mandatory',
    last-rc-change='Wed Dec 20 09:19:28 2017', queued=0ms, exec=26ms
* tlxdmz-nfs1-cluster_ip-1_monitor_0 on tlxdmz-nfs1 'not configured' (6): 
call=23, status=complete, exitreason='IP address (the ip parameter) is 
mandatory',
    last-rc-change='Wed Dec 20 09:19:28 2017', queued=0ms, exec=24ms
* tlxdmz-nfs2-cluster_ip-1_monitor_0 on tlxdmz-nfs1 'not configured' (6): 
call=27, status=complete, exitreason='IP address (the ip parameter) is 
mandatory',
    last-rc-change='Wed Dec 20 09:19:28 2017', queued=0ms, exec=61ms


Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

Any suggestion how this can be fixed when enabling nfs-ganesha when invoking 
the above command or anything else that I can do to fixed the failed actions?

Thanks

___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users