search for: gd1

...riendly as possible. We're getting this out here now, because there was quite a bit of concern and confusion regarding the upgrades between 3.x and 4.0+. --- ## Background Gluster-4.0 will bring a newer management daemon, GlusterD-2.0 (GD2), which is backwards incompatible with the GlusterD (GD1) in GlusterFS-3.1+. As a hybrid cluster of GD1 and GD2 cannot be established, rolling upgrades are not possible. This meant that upgrades from 3.x to 4.0 would require a volume downtime and possible client downtime. This was a cause of concern among many during the recently concluded Gluster Summ...

...etting this out here now, because there was quite a bit of > concern and confusion regarding the upgrades between 3.x and 4.0+. > > --- > ## Background > > Gluster-4.0 will bring a newer management daemon, GlusterD-2.0 (GD2), > which is backwards incompatible with the GlusterD (GD1) in > GlusterFS-3.1+. As a hybrid cluster of GD1 and GD2 cannot be > established, rolling upgrades are not possible. This meant that > upgrades from 3.x to 4.0 would require a volume downtime and possible > client downtime. > > This was a cause of concern among many during the re...

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 enough to start the correct vers...

...e 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 clarify if that?s what we?re used to as a rolling upgrade or how it works, that would be appreciated. Also clarification that we?ll be able to upgrade from 3.x (3.1x?) to 4.0, manually or automatically? > From:...

...the amount of manual intervention to be minimal. The least minimum amount of manual work needed would be enabling and starting GD2 and starting the migration script. > > 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. With the described upgrade strategy, we can ensure continuous volume access to clients during the whole process (provided volumes have been setup with replication or ec). During the migration from GD1 to GD2, any existing clients still retain access...

...cause there was quite a bit of >> concern and confusion regarding the upgrades between 3.x and 4.0+. >> >> --- >> ## Background >> >> Gluster-4.0 will bring a newer management daemon, GlusterD-2.0 (GD2), >> which is backwards incompatible with the GlusterD (GD1) in >> GlusterFS-3.1+. As a hybrid cluster of GD1 and GD2 cannot be >> established, rolling upgrades are not possible. This meant that >> upgrades from 3.x to 4.0 would require a volume downtime and possible >> client downtime. >> >> This was a cause of concern...

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 does the upgrade script do this?) > > > I assume that once the cluster had been migrated to GD2 the glusterd startup > script will...

...>> concern and confusion regarding the upgrades between 3.x and 4.0+. > >> > >> --- > >> ## Background > >> > >> Gluster-4.0 will bring a newer management daemon, GlusterD-2.0 (GD2), > >> which is backwards incompatible with the GlusterD (GD1) in > >> GlusterFS-3.1+. As a hybrid cluster of GD1 and GD2 cannot be > >> established, rolling upgrades are not possible. This meant that > >> upgrades from 3.x to 4.0 would require a volume downtime and possible > >> client downtime. > >> > >&gt...

...nfusion regarding the upgrades between 3.x and 4.0+. >> >> >> >> --- >> >> ## Background >> >> >> >> Gluster-4.0 will bring a newer management daemon, GlusterD-2.0 (GD2), >> >> which is backwards incompatible with the GlusterD (GD1) in >> >> GlusterFS-3.1+. As a hybrid cluster of GD1 and GD2 cannot be >> >> established, rolling upgrades are not possible. This meant that >> >> upgrades from 3.x to 4.0 would require a volume downtime and possible >> >> client downtime. >> &...

...rp <- factor(rep(1:2,c(10,10))) Now, at this point, I think I should be able to do something like this: lme(a12~grp) or lme(a12~1|grp) but I keep getting an error message, "Invalid formula for groups." So I tried making a groupedData object: data1 <- as.data.frame(cbind(a12,grp)) gd1 <- groupedData(a12~1|grp,data=as.data.frame(cbind(a12,grp))) Now I can do lme(gd1) or lme(gd1,random=1|grp) or many other things, but nothing seems to yield anything like the t test, and I'm not even sure what the fixed effect test (with a p of .011 with summary(lme(gd1))) is testing. (It...

I need to upgrade gd from 1.8 to 2.x, but can't find any rpm's to do so. If I try to rebuild a .src.rpm, I get into a dependency hell. Does anyone know how I can accomplish this upgrade without getting into a source install? Mike

Hi I need to get libgd.so.1.8 onto a CentOS 4 system - Currently its at 4.2 and i see that this is in package gd1.x however for CentOS 4 there is only gd2.x How can i get this lib ? thanks

Hi all! After that good thread "DGD patch not detecting dead gateway" I was able to set up a Load Balancing with ping based DGD (without Julian Anastasov patch). But now I''m facing a new problem and tried some options, with only partial solutions. I made a script based on http://www.mail-archive.com/lartc@mailman.ds9a.nl/msg16257.html (Thank you Manish Kathuria),

Hello list. I'm trying to rebuild the 2.6.9.67.0.20.EL kernel, but it fails even without modifications. How did I try it? Created a (non-root) build environment (not a mock ) Installed the kernel.scr.rpm and did a rpmbuild -ba --target=`uname -m` kernel-2.6.spec 2> prep-err.log | tee prep-out.log The build failed at the end: Processing files: kernel-xenU-devel-2.6.9-67.0.20.EL Checking

depends on "autoconf: regenerate configure scripts with 4.4 version" This series removes some of the really old deadwood from the tools build and makes some other things which are on their way out configurable at build time with a default depending on how far down the slope I judge them to be. * nuke in tree copy of libaio * nuke obsolete tools: xsview, miniterm, lomount & sv *