similar to: Request for Comments: Upgrades from 3.x to 4.0+

if doing an upgrade from 3.10.1 to 4.0 or 4.1, will I be able to access volume without any challenge? I am asking this because 4.0 comes with DHT2? On Thu, Nov 2, 2017 at 2:26 PM, Kaushal M <kshlmster at gmail.com> wrote: > We're fast approaching the time for Gluster-4.0. And we would like to > set out the expected upgrade strategy and try to polish it to be as > user

On Thu, Nov 2, 2017 at 4:00 PM, Amudhan P <amudhan83 at gmail.com> wrote: > if doing an upgrade from 3.10.1 to 4.0 or 4.1, will I be able to access > volume without any challenge? > > I am asking this because 4.0 comes with DHT2? Very short answer, yes. Your volumes will remain the same. And you will continue to access them the same way. RIO (as DHT2 is now known as) developers

does RIO improves folder listing and rebalance, when compared to 3.x? if yes, do you have any performance data comparing RIO and DHT? On Thu, Nov 2, 2017 at 4:12 PM, Kaushal M <kshlmster at gmail.com> wrote: > On Thu, Nov 2, 2017 at 4:00 PM, Amudhan P <amudhan83 at gmail.com> wrote: > > if doing an upgrade from 3.10.1 to 4.0 or 4.1, will I be able to access > > volume

Just so I am clear the upgrade process will be as follows: upgrade all clients to 4.0 rolling upgrade all servers to 4.0 (with GD1) kill all GD1 daemons on all servers and run upgrade script (new clients unable to connect at this point) start GD2 ( necessary or does the upgrade script do this?) I assume that once the cluster had been migrated to GD2 the glusterd startup script will be smart

On Fri, Nov 3, 2017 at 8:50 PM, Alastair Neil <ajneil.tech at gmail.com> wrote: > Just so I am clear the upgrade process will be as follows: > > upgrade all clients to 4.0 > > rolling upgrade all servers to 4.0 (with GD1) > > kill all GD1 daemons on all servers and run upgrade script (new clients > unable to connect at this point) > > start GD2 ( necessary or

Will the various client packages (centos in my case) be able to automatically handle the upgrade vs new install decision, or will we be required to do something manually to determine that? It?s a little unclear that things will continue without interruption because of the way you describe the change from GD1 to GD2, since it sounds like it stops GD1. Early days, obviously, but if you could

On Thu, Nov 2, 2017 at 7:53 PM, Darrell Budic <budic at onholyground.com> wrote: > Will the various client packages (centos in my case) be able to > automatically handle the upgrade vs new install decision, or will we be > required to do something manually to determine that? We should be able to do this with CentOS (and other RPM based distros) which have well split glusterfs

Hi Amudhan, Please go through the following that would clarify up-gradation concerns from DHT to RIO in 4.0 1. RIO would not deprecate DHT. Both DHT and RIO would co-exist. 2. DHT volumes would not be migrated to RIO. DHT volumes would still be using DHT code. 3. The new volume creation should specifically opt for RIO volume once RIO is in place. 4. RIO should be perceived as

The Gluster community celebrates 13 years of development with this latest release, Gluster 4.0. This release enables improved integration with containers, an enhanced user experience, and a next-generation management framework. The 4.0 release helps cloud-native app developers choose Gluster as the default scale-out distributed file system. We?re highlighting some of the announcements, major

Meeting date: 05/02/2018 (May 02nd, 2018), 19:30 IST, 14:00 UTC, 10:00 EDT BJ Link * Bridge: https://bluejeans.com/205933580 * Download: <TBD> Attendance * Raghavendra M (Raghavendra Bhat), Kaleb, Atin, Amar, Nithya, Rafi, Shyam Agenda * Commitment (GPLv2 Cure) * Email and Patch * [amarts] 20+ people already have done +1. Will wait another

After nearly 3 months, we have another preview release for GlusterD-2.0. The highlights for this release are, - GD2 now uses an auto scaling etcd cluster, which automatically selects and maintains the required number of etcd servers in the cluster. - Preliminary support for volume expansion has been added. (Note that rebalancing is not available yet) - An end to end functional testing framework

On Sun, 11 Jun 2017 at 06:25, Lindsay Mathieson <lindsay.mathieson at gmail.com> wrote: > On 11/06/2017 10:46 AM, WK wrote: > > I thought you had removed vna as defective and then ADDED in vnh as > > the replacement? > > > > Why is vna still there? > > Because I *can't* remove it. It died, was unable to be brought up. The > gluster peer detach command

Hi, I have a cluster of 10 servers all running Fedora 24 along with Gluster 3.8. I'm planning on doing rolling upgrades to Fedora 27 with Gluster 3.12. I saw the documentation and did some testing but I would like to run my plan through some (more?) educated minds. The current setup is: Volume Name: vol0 Distributed-Replicate Number of Bricks: 2 x (2 + 1) = 6 Bricks: Brick1:

On 11/06/2017 10:46 AM, WK wrote: > I thought you had removed vna as defective and then ADDED in vnh as > the replacement? > > Why is vna still there? Because I *can't* remove it. It died, was unable to be brought up. The gluster peer detach command only works with live servers - A severe problem IMHO. -- Lindsay Mathieson

I have not done the upgrade yet. Since this is a production cluster I need to make sure it stays up or schedule some downtime if it doesn't doesn't. Thanks. On Tue, Dec 19, 2017 at 10:11 AM, Atin Mukherjee <amukherj at redhat.com> wrote: > > > On Tue, Dec 19, 2017 at 1:10 AM, Ziemowit Pierzycki <ziemowit at pierzycki.com> > wrote: >> >> Hi, >>

Hi Diego, Just to clarify, so did you do an offline upgrade with an existing cluster (3.6.x => 3.10.x)? Thanks. On Fri, Aug 25, 2017 at 8:42 PM, Diego Remolina <dijuremo at gmail.com> wrote: > I was never able to go from 3.6.x to 3.7.x without downtime. Then > 3.7.x did not work well for me, so I stuck with 3.6.x until recently. > I went from 3.6.x to 3.10.x but downtime was

On Tue, Dec 19, 2017 at 1:10 AM, Ziemowit Pierzycki <ziemowit at pierzycki.com> wrote: > Hi, > > I have a cluster of 10 servers all running Fedora 24 along with > Gluster 3.8. I'm planning on doing rolling upgrades to Fedora 27 with > Gluster 3.12. I saw the documentation and did some testing but I > would like to run my plan through some (more?) educated minds. >

Yes, I did an offline upgrade. 1. Stop all clients using gluster servers. 2. Stop glusterfsd and glusterd on both servers. 3. Backed up /var/lib/gluster* in all servers just to be safe. 4. Upgraded all servers from 3.6.x to 3.10.x (I did not have quotas or anything that required special steps) 5. Started gluster daemons again and confirmed everything was fine prior to letting clients connect. 5.

Looks like a bug as I see tier-enabled = 0 is an additional entry in the info file in shchhv01. As per the code, this field should be written into the glusterd store if the op-version is >= 30706 . What I am guessing is since we didn't have the commit 33f8703a1 "glusterd: regenerate volfiles on op-version bump up" in 3.8.4 while bumping up the op-version the info and volfiles were

On Thu, Apr 26, 2018 at 9:06 PM Mark Staudinger <mark.staudinger at nyi.net> wrote: > Hi Folks, > I'm trying to debug an issue that I've found while attempting to qualify > GlusterFS for potential distributed storage projects on the FreeBSD-11.1 > server platform - using the existing package of GlusterFS v3.11.1_4 > The main issue I've encountered is that I