glusterfs 3.3.0 is available at http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.0/glusterfs-3.3.0.tar.gz
Created attachment 315303 [details] Ebuild for glusterfs 3.3.0 Based on gluster 3.2.6 ebuild. Minor modifications removing a few patchs that seemed unnecessary (and weren't working), including a new USE flag: georeplication and copying more files to doc
Created attachment 315305 [details, diff] docdir patch for gluster 3.3.0 ebuild
I believe the directory changes made by upstream won't impact Gentoo installations as the directory used by Gluster 3.3.0 is the same Gentoo's Gluster was using.
Alexey: Need any help with this bump? I could really use having 3.3.0 in the tree soon for my own purposes. If you don't mind, I could help with this bump and maybe help maintain. Thanks!
@Lance : we're not a very territorial herd so I guess you can go for it if you feel like it now that's it's not a beta anymore. Cheers
Hi all, I can confirm the ebuild is working correctly (for me at least), if that helps speed things up. Migration from 3.2.X to 3.3.0 looks like it can be automated as per instructions from http://vbellur.wordpress.com/2012/05/31/upgrading-to-glusterfs-3-3/ to an extent. Basically /etc/glusterfs needs to be moved to /usr/lib/glusterfs, however, it looks like the entire cluster has to be shut down at the same time to perform the update ... not sure how to incorporate that into an ebuild ... fortunately I didn't have an older cluster to migrate. Haven't tested glusterfsd, but rather using glusterd.
(In reply to comment #6) > Migration from 3.2.X to 3.3.0 looks like it can be automated as per > instructions from > http://vbellur.wordpress.com/2012/05/31/upgrading-to-glusterfs-3-3/ to an > extent. Basically /etc/glusterfs needs to be moved to /usr/lib/glusterfs, > however, it looks like the entire cluster has to be shut down at the same > time to perform the update ... not sure how to incorporate that into an > ebuild ... fortunately I didn't have an older cluster to migrate. Upstream produced a update path way more complicated that we can expect to deal automatically through an ebuild. I believe the ebuild should only direct the user to http://vbellur.wordpress.com/2012/05/31/upgrading-to-glusterfs-3-3/ so she/he knows what has to be done besides updating the software itself.
The RPMs managed it, except for the fact that you have to shut down glusterd on all nodes of the cluster - so yes, it's definitely downtime. Suggested routes? I've got a gluster on 3.3.0 up and running (seems to handle itself MUCH better than gfs), so would appreciate getting the ebuild into the tree at some point. A question I do have to ask ... is there any way to allow new people installing to automatically merge 3.3.0 (even if I have to spec ~), but to prevent people already having 3.2.X installed from accidentally merging 3.3.X without some explicit action to indicate "yes, I am aware of the consequences and I do plan to proceed with this!"?
I use it since the ebuild was posted here. I haven't experienced instabilitys, once the oom killed the glusterfsd process, but it wasn't the fault of gluster as later turned out, so I think the ebuild should be in the portage tree as it's a working, and stable product. I use 3.3 for the first time, so I can't say anything about migration...
(In reply to comment #8) > The RPMs managed it, except for the fact that you have to shut down glusterd > on all nodes of the cluster - so yes, it's definitely downtime. > > Suggested routes? I've got a gluster on 3.3.0 up and running (seems to > handle itself MUCH better than gfs), so would appreciate getting the ebuild > into the tree at some point. > > A question I do have to ask ... is there any way to allow new people > installing to automatically merge 3.3.0 (even if I have to spec ~), but to > prevent people already having 3.2.X installed from accidentally merging > 3.3.X without some explicit action to indicate "yes, I am aware of the > consequences and I do plan to proceed with this!"? Nope, we can only warn and pray that people read it. I'll put the new version to portage today
(In reply to comment #10) > (In reply to comment #8) > > The RPMs managed it, except for the fact that you have to shut down glusterd > > on all nodes of the cluster - so yes, it's definitely downtime. > > > > Suggested routes? I've got a gluster on 3.3.0 up and running (seems to > > handle itself MUCH better than gfs), so would appreciate getting the ebuild > > into the tree at some point. > > > > A question I do have to ask ... is there any way to allow new people > > installing to automatically merge 3.3.0 (even if I have to spec ~), but to > > prevent people already having 3.2.X installed from accidentally merging > > 3.3.X without some explicit action to indicate "yes, I am aware of the > > consequences and I do plan to proceed with this!"? > Nope, we can only warn and pray that people read it. I'll put the new > version to portage today BTW, we're using /var/lib/glusterd since 3.2.0 in Gentoo, so it shouldn't be hard to upgrade, just /etc/init.d/gluster{,fs}d stop ; glusterd –xlator-option *.upgrade=on -N
I've submitted a couple of patches upstream, I'd like to wait for the reaction before bumping
+*glusterfs-3.3.0 (26 Sep 2012) + + 26 Sep 2012; Kacper Kowalik <xarthisius@gentoo.org> + +files/glusterfs-3.3.0-avoid-version.patch, + +files/glusterfs-3.3.0-docdir.patch, + +files/glusterfs-3.3.0-parallel-build.patch, + +files/glusterfs-3.3.0-silent_rules.patch, +glusterfs-3.3.0.ebuild: + Version bump wrt #419643 by Rodrigo Severo <rodrigo@fabricadeideias.com>
