Re: [Gluster-devel] Release 4.1: LTM release targeted for end of May
Hi, I would like to (rep)propose lease support https://github.com/gluster/glusterfs/issues/350 Current status Following patches posted : https://review.gluster.org/#/c/19568/ -- gfapi recall lease https://review.gluster.org/#/c/12496/ -- test case https://review.gluster.org/#/c/11721/ -- add lease fop for afr need to sent a patch for adding lease fop in ec + I have patch for bug fixes in current lease implementation Regards, Jiffin On Tuesday 13 March 2018 07:07 AM, Shyam Ranganathan wrote: Hi, As we wind down on 4.0 activities (waiting on docs to hit the site, and packages to be available in CentOS repositories before announcing the release), it is time to start preparing for the 4.1 release. 4.1 is where we have GD2 fully functional and shipping with migration tools to aid Glusterd to GlusterD2 migrations. Other than the above, this is a call out for features that are in the works for 4.1. Please *post* the github issues to the *devel lists* that you would like as a part of 4.1, and also mention the current state of development. Further, as we hit end of March, we would make it mandatory for features to have required spec and doc labels, before the code is merged, so factor in efforts for the same if not already done. Current 4.1 project release lane is empty! I cleaned it up, because I want to hear from all as to what content to add, than add things marked with the 4.1 milestone by default. Thanks, Shyam P.S: Also any volunteers to shadow/participate/run 4.1 as a release owner? ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [release-4.0] FAILED ./tests/bugs/ec/bug-1236065.t
Patch at https://review.gluster.org/19746 On Tue, Mar 20, 2018 at 8:42 PM, Milind Changire wrote: > Jenkins Job: https://build.gluster.org/job/centos7-regression/405/ > consoleFull > > -- > Milind > > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] [release-4.0] FAILED ./tests/bugs/ec/bug-1236065.t
Jenkins Job: https://build.gluster.org/job/centos7-regression/405/consoleFull -- Milind ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-Maintainers] Release 4.1: LTM release targeted for end of May
On 03/14/2018 12:05 PM, Aravinda wrote: > On 03/14/2018 05:38 PM, Shyam Ranganathan wrote: >> On 03/14/2018 02:40 AM, Aravinda wrote: >>> I have following suggestion for managing release notes. Let me know >>> if this can be included in automation document. >> Aravinda, I assume this is an additional suggestion, orthogonal to the >> current discussion around spec and docs, right? > Yes. Sorry about that. No worries, setting the context was important (to me). >> >>> >>> If a Github issue used in Commit message as "Fixes: #" then Smoke >>> test should fail if patch does not contain >>> `$SRC/release-notes/.md` >>> (if `$SRC/release-notes/.md` not already exists in codebase) >>> >>> On branching, delete all these release-notes from Master branch and >>> start >>> fresh. Release branch now contains these notes for all the features >>> went in after the last release. Release manager's job is to merge all >>> these release notes into single release notes document. >>> >>> We can restrict on the format of release-note as, >>> >>> First Line is Title >>> Tags: component-name, keywords etc >>> -- >>> Description about the feature, example, links etc >>> >>> If all patches are submitted with `Updates` instead of `Fixes`, then >>> Issue can't be closed without submitting patch with release-note. >> Most of the above is fine and we can thrash out specifics, but... >> >> I am thinking differently, if spec and doc are provided writing a short >> 1-5 line summary in the release notes is not a problem. > > I think developer who developed the feature is the best person to write > the release notes. Release notes are easy to write while developing the > feature or just after finishing the feature. Once developer starts working > on other features/bug fixes it is very difficult to get interest in writing > release-note for an already merged feature. > > I think extracting summary from the documentation is also difficult, if the > release maintainer not aware of all the features then it will be more > time-consuming to write summary. I agree to a lot of the points, if the author provided the required release note it would be perfect (edits for style and other such will still happen, but are far less technical in nature). I am all for a bot that reminds folks that release notes are pending and hence cannot merge the code. The nature of implementing this, a separate release-notes.md file update in the commit, or a separate section in the design document/text is something we can debate about. We are instating a process of requiring the design doc and getting a "DocApproved" flag. Now, this doc and its approval flag can be granted once appropriate release notes are also present, that way we have one place to do this and one flag to worry about, thoughts? > >> >> The issue at present is that, to get contents into the release notes, at >> times even the code has to be read to understand options, defaults and >> what not. This being done by one person has been a challenge. >> >> So if we address spec and doc, I/we can check how easy it is to write >> release notes from these (over the next couple of releases say) and then >> decide if we want authors to provide the release notes as well. >> >> Thoughts? >> >> Shyam > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Release 4.1: LTM release targeted for end of May
On 03/12/2018 09:37 PM, Shyam Ranganathan wrote: > Hi, > > As we wind down on 4.0 activities (waiting on docs to hit the site, and > packages to be available in CentOS repositories before announcing the > release), it is time to start preparing for the 4.1 release. > > 4.1 is where we have GD2 fully functional and shipping with migration > tools to aid Glusterd to GlusterD2 migrations. > > Other than the above, this is a call out for features that are in the > works for 4.1. Please *post* the github issues to the *devel lists* that > you would like as a part of 4.1, and also mention the current state of > development. Thanks for those who responded. The github lane and milestones for the said features are updated, request those who mentioned issues being tracked for 4.1 check that these are reflected in the project lane [1]. I have few requests as follows that if picked up would be a good thing to achieve by 4.1, volunteers welcome! - Issue #224: Improve SOS report plugin maintenance - https://github.com/gluster/glusterfs/issues/224 - Issue #259: Compilation warnings with gcc 7.x - https://github.com/gluster/glusterfs/issues/259 - Issue #411: Ensure python3 compatibility across code base - https://github.com/gluster/glusterfs/issues/411 - NFS Ganesha HA (storhaug) - Does this need an issue for Gluster releases to track? (maybe packaging) I will close the call for features by Monday 26th Mar, 2018. Post this, I would request that features that need to make it into 4.1 be raised as exceptions to the devel and maintainers list for evaluation. > > Further, as we hit end of March, we would make it mandatory for features > to have required spec and doc labels, before the code is merged, so > factor in efforts for the same if not already done. > > Current 4.1 project release lane is empty! I cleaned it up, because I > want to hear from all as to what content to add, than add things marked > with the 4.1 milestone by default. [1] 4.1 Release lane: https://github.com/gluster/glusterfs/projects/1#column-1075416 > > Thanks, > Shyam > P.S: Also any volunteers to shadow/participate/run 4.1 as a release owner? Calling this out again! > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Coverity covscan for 2018-03-20-2a326ad3 (master branch)
GlusterFS Coverity covscan results are available from http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2018-03-20-2a326ad3 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Release 4.0.1: Slated for tomorrow
Hi, The first minor update for 4.0 is here (already!). 20th of each month was the day of release, I am postponing this by a day, as we did not announce this clearly to the lists, and hence want to give this 24 hours post announcement for any stragglers to make it. One patch that is still under review is https://review.gluster.org/#/c/19660/ (Du/Milind can you please rebase this so that it can be merged). Thanks, Shyam [1] 4.0.1 tracker bug: https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-4.0.1 [2] Release schedule: https://www.gluster.org/release-schedule/ ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Announcing Softserve- serve yourself a VM
Please file an issue for this: https://github.com/gluster/softserve/issues/new On Tue, Mar 20, 2018 at 1:57 PM, Sanju Rakonde wrote: > Hi Nigel, > > I have a suggestion here. It will be good if we have a option like request > for extension of the VM duration, and the option will be automatically > activated after 3 hours of usage of VM. If somebody is using the VM after 3 > hours and they feel like they need it for 2 more hours they will request to > extend the duration by 1 more hour. It will save the time of engineering > since if a machine is expired, one has to configure the machine and all > other stuff from the beginning. > > Thanks, > Sanju > > On Tue, Mar 13, 2018 at 12:37 PM, Nigel Babu wrote: > >> >> We’ve enabled certain limits for this application: 1. Maximum allowance of 5 VM at a time across all the users. User have to wait until a slot is available for them after 5 machines allocation. 2. User will get the requesting machines maximum upto 4 hours. >>> IMHO ,max cap of 4 hours is not sufficient. Most of the times, the >>> reason of loaning a machine is basically debug a race where we can't >>> reproduce the failure locally what I have seen debugging such tests might >>> take more than 4 hours. Imagine you had done some tweaking to the code and >>> you're so close to understand the problem and then the machine expires, >>> it's definitely not a happy feeling. What are the operational challenges if >>> we have to make it for atleast 8 hours or max a day? >>> >> >> The 4h cap was kept so that multiple people could have a chance to debug >> their test failures on the same day. Pushing the cap to 8h means that if >> you don't have a machine to loan when you start work one will not be >> available until the next day. At this point, we'll not be increasing the >> timeout. So far, we've had one person actually hit this. I'd like to see >> more data points before we make an application level change. >> >> -- >> nigelb >> >> ___ >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> http://lists.gluster.org/mailman/listinfo/gluster-devel >> > > -- nigelb ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Announcing Softserve- serve yourself a VM
Hi Nigel, I have a suggestion here. It will be good if we have a option like request for extension of the VM duration, and the option will be automatically activated after 3 hours of usage of VM. If somebody is using the VM after 3 hours and they feel like they need it for 2 more hours they will request to extend the duration by 1 more hour. It will save the time of engineering since if a machine is expired, one has to configure the machine and all other stuff from the beginning. Thanks, Sanju On Tue, Mar 13, 2018 at 12:37 PM, Nigel Babu wrote: > > We’ve enabled certain limits for this application: >>> >>>1. >>> >>>Maximum allowance of 5 VM at a time across all the users. User have >>>to wait until a slot is available for them after 5 machines allocation. >>>2. >>> >>>User will get the requesting machines maximum upto 4 hours. >>> >>> >> IMHO ,max cap of 4 hours is not sufficient. Most of the times, the reason >> of loaning a machine is basically debug a race where we can't reproduce the >> failure locally what I have seen debugging such tests might take more than >> 4 hours. Imagine you had done some tweaking to the code and you're so close >> to understand the problem and then the machine expires, it's definitely not >> a happy feeling. What are the operational challenges if we have to make it >> for atleast 8 hours or max a day? >> > > The 4h cap was kept so that multiple people could have a chance to debug > their test failures on the same day. Pushing the cap to 8h means that if > you don't have a machine to loan when you start work one will not be > available until the next day. At this point, we'll not be increasing the > timeout. So far, we've had one person actually hit this. I'd like to see > more data points before we make an application level change. > > -- > nigelb > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
