[Gluster-devel] GlusterFS-3.4.4beta is slipping
At last week's community meeting we tentatively agreed that today — May 14th — we would ship 3.4.4beta. Three changes for 3.4.4 need to be reviewed before they can be merged: 1 Ubuntu code audit results (blocking inclusion in Ubuntu Main repo): https://bugzilla.redhat.com/show_bug.cgi?id=1086460 http://review.gluster.org/#/c/7583/ (also http://review.gluster.org/#/c/7605/ for 3.5.1) 2 Addition of new server after upgrade from 3.3 results in peer rejected: https://bugzilla.redhat.com/show_bug.cgi?id=1090298 http://review.gluster.org/#/c/7729/ 3 Disabling NFS causes E level errors in nfs.log: https://bugzilla.redhat.com/show_bug.cgi?id=1095330 http://review.gluster.org/#/c/7699/ And Joe Julian added https://bugzilla.redhat.com/show_bug.cgi?id=1095596 as a blocker for 3.4.4 — Stick to IANA standard while allocating brick ports. This needs a port or rebase of http://review.gluster.com/#/c/3339/ -- Kaleb ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] GlusterFS-3.4.4beta is slipping
On 05/14/2014 05:04 PM, Kaleb S. KEITHLEY wrote: At last week's community meeting we tentatively agreed that today — May 14th — we would ship 3.4.4beta. Three changes for 3.4.4 need to be reviewed before they can be merged: 1 Ubuntu code audit results (blocking inclusion in Ubuntu Main repo): https://bugzilla.redhat.com/show_bug.cgi?id=1086460 http://review.gluster.org/#/c/7583/ (also http://review.gluster.org/#/c/7605/ for 3.5.1) 2 Addition of new server after upgrade from 3.3 results in peer rejected: https://bugzilla.redhat.com/show_bug.cgi?id=1090298 http://review.gluster.org/#/c/7729/ While the patch that I sent works, my RCA doesn't seem to be right. I'll look into it to it and see if I can get to the correct fix. -Ravi 3 Disabling NFS causes E level errors in nfs.log: https://bugzilla.redhat.com/show_bug.cgi?id=1095330 http://review.gluster.org/#/c/7699/ And Joe Julian added https://bugzilla.redhat.com/show_bug.cgi?id=1095596 as a blocker for 3.4.4 — Stick to IANA standard while allocating brick ports. This needs a port or rebase of http://review.gluster.com/#/c/3339/ -- Kaleb ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Release of 3.5.1 alpha/rc slipping
At last week's community meeting we tentatively agreed on today — May 14th — as the date we would release 3.5.1alpha. There are several bugs attached to the blocker for glusterfs-3.5.1 [1]. Not all of them have either ... - ... received patches (mostly documentation additions from features, carried over from the 3.5.0 release), these are in NEW status - ... do not have a corresponding patch merged in master, these have a depends-on bug that is not in MODIFIED status The dependency tree shows the main tracker bug on top, the 1st level of indention are the bugs that need to be resolved for 3.5.1, and any deeper level indicates that the 3.5.1 bug has a dependency on a bug in the master branch. The most urgent bug that needs to be resolved for a 3.5.1 release would be bug 1089054, which depends on bug 1038391 for the master branch. This problem makes it more difficult for distributions to package the release, some files are missing in the 'make dist' tarball and need to be regenerated. I have sent http://review.gluster.org/7714 for review, but it seems to have failed regression testing (rpmbuild). I am unsure why, local builds pass fine. I'd appreciate it if anyone can have a look at it. (The fact that regression testing is very slow, and the long queue in Jenkins does not help.) I'd like to make an alpha or release-candidate available later this week, assuming that bug 1089054 gets resolved. The documentation additions have been skipped the last release too already, and there is no publicly available rendered documentation site available, making end-user documentation close to unusable anyway. Comments, ideas and further discussion on this topic is very welcome. Please voice your opinions and respond to this email, or let yourself be heard in the community meeting planned for later today. Thanks, Niels ¹ https://bugzilla.redhat.com/showdependencytree.cgi?hide_resolved=0id=glusterfs-3.5.1 ² http://review.gluster.org/#/q/project:glusterfs+branch:release-3.5+status:open+NOT+topic:rfc,n,z ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Reminder: Weekly Gluster Community meeting is in 1 hour
Reminder!!! The weekly Gluster Community meeting is in 1 hour, in #gluster-meeting on IRC. This is a completely public meeting, everyone is encouraged to attend and be a part of it. :) To add Agenda items *** Just add them to the main text of the Google Doc, and **be at the meeting**. :) Agenda - http://goo.gl/XDv6jf + Justin -- Open Source and Standards @ Red Hat twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Reminder: Weekly Gluster Community meeting is in 1 hour
On 14/05/2014, at 3:02 PM, Justin Clift wrote: Reminder!!! The weekly Gluster Community meeting is in 1 hour, in #gluster-meeting on IRC. This is a completely public meeting, everyone is encouraged to attend and be a part of it. :) To add Agenda items *** Just add them to the main text of the Google Doc, and **be at the meeting**. :) Agenda - http://goo.gl/XDv6jf Thanks to everyone for attending. :) Meeting summary here: http://meetbot.fedoraproject.org/gluster-meeting/2014-05-14/gluster-meeting.2014-05-14-15.01.html Full meeting log here: http://meetbot.fedoraproject.org/gluster-meeting/2014-05-14/gluster-meeting.2014-05-14-15.01.log.html Regards and best wishes, Justin Clift -- Open Source and Standards @ Red Hat twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Regression tests: Should we test non-XFS too?
On 05/14/2014 04:20 AM, Joe Julian wrote: On 5/13/2014 2:55 PM, Dan Mons wrote: Not trying to start a flame war (don't you love posts that start like this). And also, this might be slightly off-topic in this thread... I don't take it as such. ZFS is clearly painful to use in large Linux environments due to licensing, and thus a lack of simple packaging. We avoid ZFS for this reason, and the fact that due to this reason nobody else is really using it in anger on Linux (or if they are, they're not reporting publicly, so the lack of community documentation pushes us away from it). Likewise we'll never get support from anyone for ZFS on Linux, so if it blows up in our face, we're stuck. Never the less, there are users in the community using ZFSoL. Like any community supported open-source software, if you're not using a supported platform you're pretty much on your own. I don't think that precludes us from trying to avoid breaking something that's already working for some people. To paraphrase Linus, if it breaks [storage] it's a [GlusterFS] bug. It would be nice to be proactive on this, imho. My personal preference is to work on mainstream, in tree file systems and to work to improve those. Just to be clear, how you (and your lawyers if you have them!) interpret the license things are up to you. More than happy to have other people test it out, but we have no plans for Red Hat employed people to do that. Same story for other out of tree file systems (some open source, some closed source) - it is up to those developers and users to test their preferred combination. And to poke back at both btrfs and zfs, I do strongly suspect that XFS (and ext4) will both out perform them for some time to come, especially on complicated storage with the largest loads. The reason to look at either ZFS or btrfs is not really performance driven in most cases. Regards, Ric BtrFS is destined to be the next big thing for Linux file systems, and roughly feature-equivalent with ZFS for the important stuff (checksumming is the big one for most of us, with the volume of data we hold, and the pain we've all faced with XFS on large volumes). Best of all it's GPL and in the kernel, and nobody has to deal with the pain of the intentionally-incompatible CDDL codebase of ZFS. What's the goal for both RHEL and GlusterFS as far as BtrFS goes? RHEL7 seems to be going the conservative path with BtrFS still being marked beta/testing. Is there a roadmap to move it on past this? Likewise the GlusterFS official docs still state XFS is the primary candidate. Is there a plan to push BtrFS more heavily for future releases? Will there be an eventual goal for both projects to make BtrFS the default target? There are use cases for each. BtrFS is slow for heavy random write workloads making it inappropriate for those if performance matters. I have no problem with ZFS - it's a great file system. The licensing sucks, however, and doesn't look like it will ever change given who the current custodians are. As long as that's the case, I'd really like to see more effort from everyone (not just GlusterFS and RHEL) pushing BtrFS as the long term goal for large Linux file systems. -Dan Dan Mons Unbreaker of broken things Cutting Edge http://cuttingedge.com.au On 14 May 2014 05:18, Joe Julian j...@julianfamily.org wrote: On Tue, May 13, 2014 6:33 am, Ric Wheeler wrote: On 05/07/2014 05:17 PM, Kaleb S. KEITHLEY wrote: On 05/06/2014 10:44 PM, B.K.Raghuram wrote: For those of us who are toying with the idea of using ZFS as the underlying filesystem but are hesitating only because it is not widely tested, a regression test on ZFS would be very welcome. If there are some issues running it at redhat for license reasons, Yes, there are issues with running it at Red Hat for exactly those reasons. License issues and in general we don't test on out of upstream tree (and I know the open zfs team itself are not the reason that it is out of tree :)) ric I thought we were upstream. Are these tests run on Red Hat equipment or at Rackspace? If we're testing things upstream from Red Hat on hosts for which Red Hat has no legal obligation, can we not test on differently licensed subsystems? Frankly, since there's no inclusion of code, headers, libraries, etc. in GlusterFS, there's no mixing of licenses. Just to have a test that shows that something still works doesn't affect copyright, in my non-legally trained opinion. would it help if someone outside ran the tests and reported the results periodically? Yes, if someone were to do that I'm sure it would be appreciated. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Regression tests: Should we test non-XFS too?
On 05/14/2014 04:20 AM, Joe Julian wrote: On 5/13/2014 2:55 PM, Dan Mons wrote: Not trying to start a flame war (don't you love posts that start like this). And also, this might be slightly off-topic in this thread... I don't take it as such. ZFS is clearly painful to use in large Linux environments due to licensing, and thus a lack of simple packaging. We avoid ZFS for this reason, and the fact that due to this reason nobody else is really using it in anger on Linux (or if they are, they're not reporting publicly, so the lack of community documentation pushes us away from it). Likewise we'll never get support from anyone for ZFS on Linux, so if it blows up in our face, we're stuck. Never the less, there are users in the community using ZFSoL. Like any community supported open-source software, if you're not using a supported platform you're pretty much on your own. I don't think that precludes us from trying to avoid breaking something that's already working for some people. To paraphrase Linus, if it breaks [storage] it's a [GlusterFS] bug. It would be nice to be proactive on this, imho. My personal preference is to work on mainstream, in tree file systems and to work to improve those. Just to be clear, how you (and your lawyers if you have them!) interpret the license things are up to you. More than happy to have other people test it out, but we have no plans for Red Hat employed people to do that. Same story for other out of tree file systems (some open source, some closed source) - it is up to those developers and users to test their preferred combination. And to poke back at both btrfs and zfs, I do strongly suspect that XFS (and ext4) will both out perform them for some time to come, especially on complicated storage with the largest loads. The reason to look at either ZFS or btrfs is not really performance driven in most cases. Regards, Ric BtrFS is destined to be the next big thing for Linux file systems, and roughly feature-equivalent with ZFS for the important stuff (checksumming is the big one for most of us, with the volume of data we hold, and the pain we've all faced with XFS on large volumes). Best of all it's GPL and in the kernel, and nobody has to deal with the pain of the intentionally-incompatible CDDL codebase of ZFS. What's the goal for both RHEL and GlusterFS as far as BtrFS goes? RHEL7 seems to be going the conservative path with BtrFS still being marked beta/testing. Is there a roadmap to move it on past this? Likewise the GlusterFS official docs still state XFS is the primary candidate. Is there a plan to push BtrFS more heavily for future releases? Will there be an eventual goal for both projects to make BtrFS the default target? There are use cases for each. BtrFS is slow for heavy random write workloads making it inappropriate for those if performance matters. I have no problem with ZFS - it's a great file system. The licensing sucks, however, and doesn't look like it will ever change given who the current custodians are. As long as that's the case, I'd really like to see more effort from everyone (not just GlusterFS and RHEL) pushing BtrFS as the long term goal for large Linux file systems. -Dan Dan Mons Unbreaker of broken things Cutting Edge http://cuttingedge.com.au On 14 May 2014 05:18, Joe Julian j...@julianfamily.org wrote: On Tue, May 13, 2014 6:33 am, Ric Wheeler wrote: On 05/07/2014 05:17 PM, Kaleb S. KEITHLEY wrote: On 05/06/2014 10:44 PM, B.K.Raghuram wrote: For those of us who are toying with the idea of using ZFS as the underlying filesystem but are hesitating only because it is not widely tested, a regression test on ZFS would be very welcome. If there are some issues running it at redhat for license reasons, Yes, there are issues with running it at Red Hat for exactly those reasons. License issues and in general we don't test on out of upstream tree (and I know the open zfs team itself are not the reason that it is out of tree :)) ric I thought we were upstream. Are these tests run on Red Hat equipment or at Rackspace? If we're testing things upstream from Red Hat on hosts for which Red Hat has no legal obligation, can we not test on differently licensed subsystems? Frankly, since there's no inclusion of code, headers, libraries, etc. in GlusterFS, there's no mixing of licenses. Just to have a test that shows that something still works doesn't affect copyright, in my non-legally trained opinion. would it help if someone outside ran the tests and reported the results periodically? Yes, if someone were to do that I'm sure it would be appreciated. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
