Re: [Gluster-devel] performance issues Manoj found in EC testing
Hi Pranith, On 28/06/16 08:08, Pranith Kumar Karampuri wrote: On Tue, Jun 28, 2016 at 10:21 AM, Poornima Gurusiddaiah mailto:pguru...@redhat.com>> wrote: Regards, Poornima *From: *"Pranith Kumar Karampuri" mailto:pkara...@redhat.com>> *To: *"Xavier Hernandez" mailto:xhernan...@datalab.es>> *Cc: *"Gluster Devel" mailto:gluster-devel@gluster.org>> *Sent: *Monday, June 27, 2016 5:48:24 PM *Subject: *Re: [Gluster-devel] performance issues Manoj found in EC testing On Mon, Jun 27, 2016 at 12:42 PM, Pranith Kumar Karampuri mailto:pkara...@redhat.com>> wrote: On Mon, Jun 27, 2016 at 11:52 AM, Xavier Hernandez mailto:xhernan...@datalab.es>> wrote: Hi Manoj, I always enable client-io-threads option for disperse volumes. It improves performance sensibly, most probably because of the problem you have detected. I don't see any other way to solve that problem. I agree. Updated the bug with same info. I think it would be a lot better to have a true thread pool (and maybe an I/O thread pool shared by fuse, client and server xlators) in libglusterfs instead of the io-threads xlator. This would allow each xlator to decide when and what should be parallelized in a more intelligent way, since basing the decision solely on the fop type seems too simplistic to me. In the specific case of EC, there are a lot of operations to perform for a single high level fop, and not all of them require the same priority. Also some of them could be executed in parallel instead of sequentially. I think it is high time we actually schedule(for which release) to get this in gluster. May be you should send out a doc where we can work out details? I will be happy to explore options to integrate io-threads, syncop/barrier with this infra based on the design may be. I was just thinking why we can't reuse synctask framework. It already scales up/down based on the tasks. At max it uses 16 threads. Whatever we want to be executed in parallel we can create a synctask around it and run it. Would that be good enough? Yes, synctask framework can be preferred over io-threads, else it would mean 16 synctask threads + 16(?) io-threads for one instance of mount, this will blow out the gfapi clients if they have many mounts from the same process. Also using synctask would mean code changes in EC? Yes it will need some changes but I don't think they are big changes. I think the functions to decode/encode already exist. We just to need to move encoding/decoding as tasks and run as synctasks. I was also thinking in sleeping fops. Currently when they are resumed, they are processed in the same thread that was processing another fop. This could add latencies to fops or unnecessary delays in lock management. If they can be scheduled to be executed by another thread, these delays are drastically reduced. On the other hand, splitting the computation of EC encoding into multiple threads is bad because current implementation takes advantage of internal CPU memory cache, which is really fast. We should compute all fragments of a single request in the same thread. Multiple independent computations could be executed by different threads. Xavi, Long time back we chatted a bit about synctask code and you wanted the scheduling to happen by kernel or something. Apart from that do you see any other issues? At least if the tasks are synchronous i.e. nothing goes out the wire, task scheduling = thread scheduling by kernel and it works exactly like thread-pool you were referring to. It does multi-tasking only if the tasks are asynchronous in nature. How would this work ? should we have to create a new synctask for each background function we want to execute ? I think this has an important overhead, since each synctask requires its own stack, creates a frame that we don't really need in most cases, and it causes context switches. We could have hundreds or thousands of requests per second. they could even require more than one background task for each request in some cases. I'm not sure if synctasks are the right choice in this case. I think that a thread pool is more lightweight. Xavi Xavi On 25/06/16 19:42, Manoj Pillai wrote: - Original Message - From: "Pranith Kumar Karampuri" mailto:pkara...@redhat.com>> To: "Xavier Hernandez" mailto
[Gluster-devel] Bugs with incorrect status
1349723 (mainline) NEW: Added libraries to get server_brick dictionaries [master] I904612 distaf: adding libraries to get server_brick dictionaries (MERGED) ** b...@gluster.org: Bug 1349723 should be MODIFIED, change I904612 has been merged ** 1279747 (mainline) MODIFIED: spec: add CFLAGS=-DUSE_INSECURE_OPENSSL to configure command-line for RHEL-5 only ** mchan...@redhat.com: No change posted, but bug 1279747 is in MODIFIED ** 1338593 (mainline) ASSIGNED: clean posix locks based on client-id as part of server_connection_cleanup [master] I661ebe posix/locks: associate posix locks with client-uuid (NEW) ** spa...@redhat.com: Bug 1338593 should be in POST, change I661ebe under review ** 1332073 (mainline) ASSIGNED: EINVAL errors while aggregating the directory size by quotad [master] If8a267 quotad: fix potential buffer overflows (NEW) [master] Iaa quotad: fix potential buffer overflows (NEW) [master] If8a267 quotad: fix potential buffer overflows (NEW) ** mselv...@redhat.com: Bug 1332073 should be in POST, change If8a267 under review ** 1349284 (mainline) ASSIGNED: [tiering]: Files of size greater than that of high watermark level should not be promoted [master] Ice0457 cluster/tier: dont promote estimated block consumption > hi watermark (NEW) ** mchan...@redhat.com: Bug 1349284 should be in POST, change Ice0457 under review ** 1202717 (mainline) MODIFIED: quota: re-factor quota cli and glusterd changes and remove code duplication ** mselv...@redhat.com: No change posted, but bug 1202717 is in MODIFIED ** 1301647 (mainline) NEW: Add support for SEEK_DATA/SEEK_HOLE to sharding [master] I0fb2d3 shard: add seek() FOP as not supported (MERGED) [master] I5c2728 shard: add seek() FOP as not supported (MERGED) ** b...@gluster.org: Bug 1301647 should be CLOSED, v3.8.0 contains a fix ** 1153964 (mainline) MODIFIED: quota: rename of "dir" fails in case of quota space availability is around 1GB [master] Iaad907 quota: No need for quota-limit check if rename is under same parent (ABANDONED) [master] I2c8140 quota: For a link operation, do quota_check_limit only till the common ancestor of src and dst file (MERGED) [master] Ia1e536 quota: For a rename operation, do quota_check_limit only till the common ancestor of src and dst file (MERGED) ** mselv...@redhat.com: Bug 1153964 should be CLOSED, v3.7.12 contains a fix ** 1341772 (3.7.11) POST: After setting up ganesha on RHEL 6, nodes remains in stopped state and grace related failures observed in pcs status [release-3.7] I726c99 common-ha: race/timing issue setting up cluster (MERGED) ** kkeit...@redhat.com: Bug 1341772 should be MODIFIED, change I726c99 has been merged ** 1332074 (3.7.10) MODIFIED: Marker: Lot of dict_get errors in brick log!! [release-3.7] I8054ff features/marker: Fix dict_get errors when key is NULL (MERGED) ** khire...@redhat.com: Bug 1332074 should be CLOSED, v3.7.12 contains a fix ** 1331263 (3.7.11) MODIFIED: SAMBA+TIER : File size is not getting updated when created on windows samba share mount [release-3.7] I90a218 gfapi: fill iatt in readdirp_cbk if entry->inode is null (MERGED) ** rkavu...@redhat.com: Bug 1331263 should be CLOSED, v3.7.12 contains a fix ** 1294675 (3.7.6) MODIFIED: Healing queue rarely empty [release-3.7] If7eee1 cluster/afr: Fix spurious entries in heal info (MERGED) ** pkara...@redhat.com: Bug 1294675 should be CLOSED, v3.7.12 contains a fix ** 1316808 (3.7.8) MODIFIED: Data Tiering:tier volume status shows as in-progress on all nodes of a cluster even if the node is not part of volume [release-3.7] Ie4345b Tier/glusterd: Resetting the tier status value to not started (MERGED) [release-3.7] I15399d Tier: displaying status only one the nodes running tierd (MERGED) ** hgowt...@redhat.com: Bug 1316808 should be CLOSED, v3.7.12 contains a fix ** 1335821 (3.7.11) MODIFIED: Revert "features/shard: Make o-direct writes work with sharding: http://review.gluster.org/#/c/13846/"; [release-3.7] Ia39f8f Revert "features/shard: Make o-direct writes work with sharding" (MERGED) ** kdhan...@redhat.com: Bug 1335821 should be CLOSED, v3.7.12 contains a fix ** 1008839 (mainline) POST: Certain blocked entry lock info not retained after the lock is granted [master] Ie37837 features/locks : Certain blocked entry lock info not retained after the lock is granted (ABANDONED) ** ata...@redhat.com: Bug 1008839 is in POST, but all changes have been abandoned ** 1339166 (mainline) POST: distaf: Added timeout value to wait for rebalance to complete and removed older rebalance library file [master] I89e2e4 Added timeout value to wait for rebalance to complete and removed older rebalance library file (MERGED) ** aloga...@redhat.com: Bug 1339166 should be MODIFIED, change I89e2e4 has been merged ** 1337899 (mainline) POST: Misleading error message on rebalance start when one of the glusterd instance is down [master] I5827d3 G
Re: [Gluster-devel] performance issues Manoj found in EC testing
> >> Yes it will need some changes but I don't think they are big changes. I >> think the functions to decode/encode already exist. We just to need to >> move encoding/decoding as tasks and run as synctasks. >> > > I was also thinking in sleeping fops. Currently when they are resumed, > they are processed in the same thread that was processing another fop. This > could add latencies to fops or unnecessary delays in lock management. If > they can be scheduled to be executed by another thread, these delays are > drastically reduced. > > On the other hand, splitting the computation of EC encoding into multiple > threads is bad because current implementation takes advantage of internal > CPU memory cache, which is really fast. We should compute all fragments of > a single request in the same thread. Multiple independent computations > could be executed by different threads. > > >> Xavi, >> Long time back we chatted a bit about synctask code and you wanted >> the scheduling to happen by kernel or something. Apart from that do you >> see any other issues? At least if the tasks are synchronous i.e. nothing >> goes out the wire, task scheduling = thread scheduling by kernel and it >> works exactly like thread-pool you were referring to. It does >> multi-tasking only if the tasks are asynchronous in nature. >> > > How would this work ? should we have to create a new synctask for each > background function we want to execute ? I think this has an important > overhead, since each synctask requires its own stack, creates a frame that > we don't really need in most cases, and it causes context switches. > Yes we will have to create a synctask. Yes it does have overhead of own stack because it assumes the task will pause at some point. I think when synctask framework was written the smallest thing that will be executed is a fop over network. It was mainly written to do replace-brick using 'pump' xlator which is now deprecated. If we know upfront that the task will never pause there is absolutely no need to create a new stack. In which case it just executes the function and moves on to the next task. > > We could have hundreds or thousands of requests per second. they could > even require more than one background task for each request in some cases. > I'm not sure if synctasks are the right choice in this case. > For each request we need to create a new synctask. It will be placed in the tasks that are ready to execute. there will be 16 threads(in the stressful scenario) waiting for new tasks, one of them will pick it up and execute. > > I think that a thread pool is more lightweight. > I think a small write-up of your thoughts on how it should be would be a good start for us. In my head a thread-pool is a set of threads waiting for incoming tasks. Each thread picks up a new task and executes the task, upon completion it will move on to the next task that needs to be executed. Synctask framework is also a thread-pool waiting for incoming tasks. Each thread picks up a task in readyq and executes the task. If the task has to pause in the middle it will have to put it in wait-q and move on to the next one. If the task never pauses, then it will complete the task execution and moves on to the next task. So synctask is more complex than thread-pool because it assumes the tasks will pause. I am wondering if we can 1) break the complexity into thread-pool which is more light-weight and add synctask framework on top of it. or alternatively 2) Optimize synctask framework to perform synchronous tasks without any stack creation and execute it in the thread stack itself. > > Xavi ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Cores generated with ./tests/geo-rep/georep-basic-dr-tarssh.t
Hi Raghavendra/Venky, Gentle reminder. Oleksander (post-factum) confirmed that their production setup has been running with this patch included since sometime and had no issues. Shall we consider merging this patch if there are no review comments? Thanks, Soumya On 03/09/2016 09:16 PM, Kotresh Hiremath Ravishankar wrote: Hi All, The following patch is sent to address changelog rpc mem-leak issues. The fix is intricate and needs lot of testing before taking in. Please review the same. http://review.gluster.org/#/c/13658/1 Thanks and Regards, Kotresh H R - Original Message - From: "Venky Shankar" To: "Raghavendra G" Cc: "Kotresh Hiremath Ravishankar" , "Gluster Devel" Sent: Monday, March 7, 2016 3:52:13 PM Subject: Re: [Gluster-devel] Cores generated with ./tests/geo-rep/georep-basic-dr-tarssh.t On Fri, Mar 04, 2016 at 02:02:32PM +0530, Raghavendra G wrote: On Thu, Mar 3, 2016 at 6:26 PM, Kotresh Hiremath Ravishankar < khire...@redhat.com> wrote: Hi, Yes, with this patch we need not set conn->trans to NULL in rpc_clnt_disable While [1] fixes the crash, things can be improved in the way how changelog is using rpc. 1. In the current code, there is an rpc_clnt object leak during disconnect event. Just for the record (as I couldn't find this information while building up rpc infrastructure in changelog): Unref rpc-clnt object after calling rpc_clnt_disable() in notify() upon RPC_CLNT_DISCONNECT. Free up 'mydata' in notify() upon RPC_CLNT_DESTROY. 2. Also, freed "mydata" of changelog is still associated with rpc_clnt object (corollary of 1), though change log might not get any events with "mydata" (as connection is dead). I've discussed with Kotresh about changes needed, offline. So, following are the action items. 1. Soumya's patch [2] is valid and is needed for 3.7 branch too. 2. [2] can be accepted. However, someone might want to re-use an rpc object after disabling it, like introducing a new api rpc_clnt_enable_again (though no of such use-cases is very less). But [2] doesn't allow it. The point is as long as rpc-clnt object is alive, transport object is alive (though disconnected) and we can re-use it. So, I would prefer not to accept it. 3. Kotresh will work on new changes to make sure changelog makes correct use of rpc-clnt. [1] http://review.gluster.org/#/c/13592 [2] http://review.gluster.org/#/c/1359 regards, Raghavendra. Thanks and Regards, Kotresh H R - Original Message - From: "Soumya Koduri" To: "Kotresh Hiremath Ravishankar" , "Raghavendra G" Cc: "Gluster Devel" Sent: Thursday, March 3, 2016 5:06:00 PM Subject: Re: [Gluster-devel] Cores generated with ./tests/geo-rep/georep-basic-dr-tarssh.t On 03/03/2016 04:58 PM, Kotresh Hiremath Ravishankar wrote: [Replying on top of my own reply] Hi, I have submitted the below patch [1] to avoid the issue of 'rpc_clnt_submit' getting reconnected. But it won't take care of memory leak problem you were trying to fix. That we have to carefully go through all cases and fix it. Please have a look at it. Looks good. IIUC, with this patch, we need not set conn->trans to NULL in 'rpc_clnt_disable()'. Right? If yes, then it takes care of memleak as the transport object shall then get freed as part of 'rpc_clnt_trigger_destroy'. http://review.gluster.org/#/c/13592/ Thanks and Regards, Kotresh H R - Original Message - From: "Kotresh Hiremath Ravishankar" To: "Soumya Koduri" Cc: "Raghavendra G" , "Gluster Devel" Sent: Thursday, March 3, 2016 3:39:11 PM Subject: Re: [Gluster-devel] Cores generated with ./tests/geo-rep/georep-basic-dr-tarssh.t Hi Soumya, I tested the lastes patch [2] on master where your previous patch [1] in merged. I see crashes at different places. 1. If there are code paths that are holding rpc object without taking ref on it, all those code path will crash on invoking rpc submit on that object as rpc object would have freed by last unref on DISCONNECT event. I see this kind of use-case in chagnelog rpc code. Need to check on other users of rpc. Agree. We should fix all such code-paths. Since this seem to be an intricate fix, shall we take these patches only in master branch and not in 3.7 release for now till we fix all such paths as we encounter? 2. And also we need to take care of reconnect timers that are being set and are re-tried to connect back on expiration. In those cases also, we might crash as rpc object would have freed. Your patch addresses this..right? Thanks, Soumya [1] http://review.gluster.org/#/c/13507/ [2] http://review.gluster.org/#/c/13587/ Thanks and Regards, Kotresh H R - Original Message - From: "Soumya Koduri" To: "Raghavendra G" , "Kotresh Hiremath Ravishankar" Cc: "Gluster Devel" Sent: Thursday, March 3, 2016 12:24:00 PM Subject: Re: [Gluster-devel] Cores generated with ./tests/geo-rep/georep-basic-dr-tarssh.t Thanks a lot Kotresh. On 03/03/2016 08:47
Re: [Gluster-devel] Cores generated with ./tests/geo-rep/georep-basic-dr-tarssh.t
Thanks for the reminder. Will take that up. - Original Message - > From: "Soumya Koduri" > To: "Venky Shankar" , "Raghavendra G" > > Cc: "Gluster Devel" > Sent: Tuesday, June 28, 2016 3:24:13 PM > Subject: Re: [Gluster-devel] Cores generated with > ./tests/geo-rep/georep-basic-dr-tarssh.t > > Hi Raghavendra/Venky, > > Gentle reminder. Oleksander (post-factum) confirmed that their > production setup has been running with this patch included since > sometime and had no issues. Shall we consider merging this patch if > there are no review comments? > > Thanks, > Soumya > > On 03/09/2016 09:16 PM, Kotresh Hiremath Ravishankar wrote: > > Hi All, > > > > The following patch is sent to address changelog rpc mem-leak issues. > > The fix is intricate and needs lot of testing before taking in. Please > > review the same. > > > > http://review.gluster.org/#/c/13658/1 > > > > Thanks and Regards, > > Kotresh H R > > > > > > - Original Message - > >> From: "Venky Shankar" > >> To: "Raghavendra G" > >> Cc: "Kotresh Hiremath Ravishankar" , "Gluster Devel" > >> > >> Sent: Monday, March 7, 2016 3:52:13 PM > >> Subject: Re: [Gluster-devel] Cores generated with > >> ./tests/geo-rep/georep-basic-dr-tarssh.t > >> > >> On Fri, Mar 04, 2016 at 02:02:32PM +0530, Raghavendra G wrote: > >>> On Thu, Mar 3, 2016 at 6:26 PM, Kotresh Hiremath Ravishankar < > >>> khire...@redhat.com> wrote: > >>> > Hi, > > Yes, with this patch we need not set conn->trans to NULL in > rpc_clnt_disable > > >>> > >>> While [1] fixes the crash, things can be improved in the way how > >>> changelog > >>> is using rpc. > >>> > >>> 1. In the current code, there is an rpc_clnt object leak during > >>> disconnect > >>> event. > >> > >> Just for the record (as I couldn't find this information while building up > >> rpc infrastructure in changelog): > >> > >> Unref rpc-clnt object after calling rpc_clnt_disable() in notify() upon > >> RPC_CLNT_DISCONNECT. Free up 'mydata' in notify() upon RPC_CLNT_DESTROY. > >> > >>> 2. Also, freed "mydata" of changelog is still associated with rpc_clnt > >>> object (corollary of 1), though change log might not get any events with > >>> "mydata" (as connection is dead). > >>> > >>> I've discussed with Kotresh about changes needed, offline. So, following > >>> are the action items. > >>> 1. Soumya's patch [2] is valid and is needed for 3.7 branch too. > >>> 2. [2] can be accepted. However, someone might want to re-use an rpc > >>> object > >>> after disabling it, like introducing a new api rpc_clnt_enable_again > >>> (though no of such use-cases is very less). But [2] doesn't allow it. The > >>> point is as long as rpc-clnt object is alive, transport object is alive > >>> (though disconnected) and we can re-use it. So, I would prefer not to > >>> accept it. > >>> 3. Kotresh will work on new changes to make sure changelog makes correct > >>> use of rpc-clnt. > >>> > >>> [1] http://review.gluster.org/#/c/13592 > >>> [2] http://review.gluster.org/#/c/1359 > >>> > >>> regards, > >>> Raghavendra. > >>> > >>> > Thanks and Regards, > Kotresh H R > > - Original Message - > > From: "Soumya Koduri" > > To: "Kotresh Hiremath Ravishankar" , "Raghavendra > G" > > Cc: "Gluster Devel" > > Sent: Thursday, March 3, 2016 5:06:00 PM > > Subject: Re: [Gluster-devel] Cores generated with > ./tests/geo-rep/georep-basic-dr-tarssh.t > > > > > > > > On 03/03/2016 04:58 PM, Kotresh Hiremath Ravishankar wrote: > >> [Replying on top of my own reply] > >> > >> Hi, > >> > >> I have submitted the below patch [1] to avoid the issue of > >> 'rpc_clnt_submit' > >> getting reconnected. But it won't take care of memory leak problem > >> you > were > >> trying to fix. That we have to carefully go through all cases and fix > it. > >> Please have a look at it. > >> > > Looks good. IIUC, with this patch, we need not set conn->trans to NULL > > in 'rpc_clnt_disable()'. Right? If yes, then it takes care of memleak > > as > > the transport object shall then get freed as part of > > 'rpc_clnt_trigger_destroy'. > > > > > >> http://review.gluster.org/#/c/13592/ > >> > >> Thanks and Regards, > >> Kotresh H R > >> > >> - Original Message - > >>> From: "Kotresh Hiremath Ravishankar" > >>> To: "Soumya Koduri" > >>> Cc: "Raghavendra G" , "Gluster Devel" > >>> > >>> Sent: Thursday, March 3, 2016 3:39:11 PM > >>> Subject: Re: [Gluster-devel] Cores generated with > >>> ./tests/geo-rep/georep-basic-dr-tarssh.t > >>> > >>> Hi Soumya, > >>> > >>> I tested the lastes patch [2] on master where your previous patch > >>> [1] > in > >>> merged. > >>> I see crashes at different places. > >>> > >>> 1. If there are code paths that are holding rpc object without > >>> taking >
[Gluster-devel] REMINDER: Gluster Bug Triage starts at 12:00 UTC (~1 hour from now)
Hi all, The Gluster Bug Triage Meeting will start in approx. 1 hour from now. Please join if you are interested in getting a decent status of bugs that have recently been filed, and maintainers/developers did not pickup yet. The meeting also includes a little bit about testing and other misc stuff related to bugs. See you there! Niels Agenda: https://public.pad.fsfe.org/p/gluster-bug-triage Location: #gluster-meeting on Freenode IRC - https://webchat.freenode.net/?channels=gluster-meeting Date: Tuesday June 28, 2016 Time: 12:00 UTC, 13:00 CET, 7:00 EST (to get your local time, run: date -d "12:00 UTC") Chair: Niels 1. Agenda - Roll Call 2. Action Items - ndevos need to decide on how to provide/use debug builds - ndevos to propose some test-cases for minimal libgfapi test - Manikandan and gem to wait until Nigel gives access to test the scripts - Manikandan will host bug triage meeting on June 21st 2016 - ndevos will host bug triage meeting on June 28th 2016 3. Group Triage 4. Open Floor signature.asc Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] GlusterFS-3.7.12 released
Hi all, I'm pleased to announce the release of GlusterFS-v3.7.12. This release includes a lot of bug fixes, that have been merged since 3.7.11. The release tarball can be downloaded from [download], and the release-notes are available at [release-notes]. Binary packages have been built for a few releases, which can be downloaded at the links below. - Fedora 23: pending testing (Updates-Testing repo), - Fedora 24, 25: [download] - Debian Wheezy, Jessie, Stretch: [download] - Ubuntu trusty, wily, xenial: [ppa] - RHEL/CentOS 5, 6, 7: [download] - SuSE packages will coming in a bit. (These packages have include one [extra-patch] on top of 3.7.12) Thank you all who made contributed to this release. Regards, Kaushal [download]: https://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.12/ [release-notes]: https://github.com/gluster/glusterfs/blob/release-3.7/doc/release-notes/3.7.12.md [ppa]: https://launchpad.net/~gluster/+archive/ubuntu/glusterfs-3.7 [extra-patch]: https://review.gluster.org/14779 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] All rpm jobs are now in jenkins job builder
Hello, All the rpm jobs are now in Jenkins job builder format. I've disabled the old jobs and replaced them with new ones: glusterfs-rpm -> rpm-fedora glusterfs-rpm-el6 -> rpm-el6 glusterfs-devrpm -> devrpm-fedora glusterfs-devrpm-el6 -> devrpm-el6 glusterfs-devrpm-el7 -> devrpm-el7 Please let me know if the old jobs are misbehaving in anyway. The code for these jobs can be seen in the pull request[1]. [1]: https://github.com/gluster/glusterfs-patch-acceptance-tests/pull/22 -- nigelb ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Minutes from todays Gluster Bug Triage meeting
Thanks all who joined! Next week at the same time (Tuesday 12:00 UTC) we will have an other bug triage meeting to catch the bugs that were not handled by developers and maintainers yet. We'll stay repeating this meeting as safety net so that bugs get the initial attention and developers can immediately start working on the issues that were reported. Bug triaging (in general, no need to only do it during the meeting) is intended to help developers, in the hope that developers can focus on writing bugfixes instead of spending much of their valued time troubleshooting incorrectly/incompletely reported bugs. More details about bug triaging can be found here: http://gluster.readthedocs.io/en/latest/Contributors-Guide/Bug-Triage/ Cheers, Niels #gluster-meeting: Gluster Bug Triage Meeting started by ndevos at 12:00:22 UTC. The full logs are available at https://meetbot.fedoraproject.org/gluster-meeting/2016-06-28/gluster_bug_triage.2016-06-28-12.00.log.html . Meeting summary --- * Agenda is at https://public.pad.fsfe.org/p/gluster-bug-triage (ndevos, 12:00:32) * Roll Call (ndevos, 12:00:40) * Next weeks meeting host (ndevos, 12:05:05) * ACTION: Saravanakmr will host next weeks meeting (ndevos, 12:06:01) * Action Items (ndevos, 12:06:12) * ndevos need to decide on how to provide/use debug builds (ndevos, 12:06:19) * ndevos to propose some test-cases for minimal libgfapi test (ndevos, 12:06:46) * Manikandan and gem to wait until Nigel gives access to test the scripts (ndevos, 12:09:37) * Group Triage (ndevos, 12:10:30) * bugs to triage have been added to https://public.pad.fsfe.org/p/gluster-bugs-to-triage (ndevos, 12:10:45) * ACTION: skoduri to remind the developers working on test-automation to triage their own bugs (ndevos, 12:19:28) * Open Floor (ndevos, 12:20:19) * Status of bugs do not get updated by developers sending patches (ndevos, 12:23:11) * ACTION: jiffin will try to add an error for bug ownership to check-bugs.py (ndevos, 12:25:59) * Open Floor #2 (ndevos, 12:27:37) Meeting ended at 12:30:07 UTC. Action Items * Saravanakmr will host next weeks meeting * skoduri to remind the developers working on test-automation to triage their own bugs * jiffin will try to add an error for bug ownership to check-bugs.py Action Items, by person --- * jiffin * jiffin will try to add an error for bug ownership to check-bugs.py * Saravanakmr * Saravanakmr will host next weeks meeting * skoduri * skoduri to remind the developers working on test-automation to triage their own bugs * **UNASSIGNED** * (none) People Present (lines said) --- * ndevos (49) * kkeithley (10) * skoduri (8) * jiffin (6) * Manikandan (5) * zodbot (3) * Saravanakmr (3) * atinm (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot signature.asc Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] **Reminder** Triaging and Updating Bug status
Hi, We have noticed that many of the bugs (esp., in the recent past the ones filed against 'tests' component) which are being actively worked upon do not have either 'Triaged' keyword set or bug status(/assignee) updated appropriately. Sometimes even many of the active community members fail to do so. Request everyone to follow the Bug triage and status guidelines [1] [2] while working on one. Thanks, Soumya [1] http://www.gluster.org/community/documentation/index.php/Bug_triage [2] https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_status ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-users] GlusterFS-3.7.12 released
On 28/06/2016 10:04 PM, Kaushal M wrote: I'm pleased to announce the release of GlusterFS-v3.7.12. This release includes a lot of bug fixes, that have been merged since 3.7.11. Brilliant, thanks everyone. -- Lindsay Mathieson ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] GlusterFS 3.9 Planning
Hi All, Are you working on any new features or enhancements to Gluster? Gluster 3.9 is coming :) As discussed previously in mailing lists, community meetings we will have a GlusterFS release in September 2016. Please share the details about features/enhancements you are working on. (Feature freeze will be around Aug 31, 2016) If you are working on a feature please open a bug and add it to 3.9.0 tracker listed below. https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.9.0 Following list of features/enhancements copied from 3.9 road map page(https://www.gluster.org/community/roadmap/3.9), Let us know if any of the features are not planned for 3.9 release. - Throttling xlator (Owners: Ravishankar N) - Trash Improvements (Owners: Anoop C S, Jiffin Tony Thottan) - Kerberos for Gluster protocols (Owners: Niels de Vos, Csaba Henk) - SELinux on Gluster Volumes (Owners: Niels de Vos, Manikandan) - DHT2 (Owners: Shyamsundar Ranganathan, Venky Shankar, Kotresh) - Native sub-directory mounts (Owners: Kaushal M, Pranith K) - RichACL support for GlusterFS (Owners: Rajesh Joseph + Volunteers) - Share modes / Share reservations (Owners: Raghavendra Talur + Poornima G, Soumya Koduri, Rajesh Joseph, Anoop C S) - Integrate with external resource management software (Owners: Kaleb Keithley, Jose Rivera) - Gluster Eventing (Owners: Aravinda VK) - Gluster Management REST APIs (Owners: Aravinda VK) - Inotify (Owners: Soumya Koduri) - pNFS Layout Recall (Owners: Jiffin Tony Thottan, Soumya Koduri) - iSCSI access for Gluster (Owners: Raghavendra Bhat, Vijay Bellur) - Directory/Files filters for Geo-replication (Owners: Kotresh, Aravinda) - Add + Remove brick with Volume Tiering (Owners: Dan Lambright) - Volume Tiering (Owners: Dan Lambright) - User and Group Quotas (Owners: Vijaikumar M, Manikandan) Feel free to add new features/enhancements to the list by creating a feature bug and attaching to the tracker. -- Thanks Aravinda & Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-users] GlusterFS-3.7.12 released
On 28 June 2016 at 22:04, Kaushal M wrote: > > I'm pleased to announce the release of GlusterFS-v3.7.12. This release > includes a lot of bug fixes, that have been merged since 3.7.11. Just did a rolling upgrade to my 3 node/rep 3 debian jessie cluster (proxmox). The process was quite painless and nobody noticed it happening. I presume that I won't get the full benefit and until I restart the VM clients (gfapi access). p.s Also noted that the opversion is now up to 30712 Cheers, -- Lindsay ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] GlusterFS 3.8.0 Postmortem
Hello, We've kicked off a thread about 3.9 planning, I figure now is a good time to do a postmortem of 3.8.0 release. Let's focus primarily on what we did bad and how we could improve[1]. My selfish interest here is to see how I can help improve our release process as the CI Engineer. I'll start off with my contribution: We upgraded Gerrit close to the release dates. This did not end up all well and may have caused stress to the release manager and delay to the release dates. It fixed our random Gerrit outages, so it has been a win, but a painful one week while we fixed everything. The postmortem for the migration[2] has the action items we'll be taking to avoid this in the future. [1]: https://codeascraft.com/2012/05/22/blameless-postmortems/ [2]: http://www.gluster.org/pipermail/gluster-infra/2016-June/002239.html -- nigelb ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
