Re: [Gluster-devel] [Gluster-Maintainers] Release 4.1: LTM release targeted for end of May
On 03/13/2018 04:00 PM, Shyam Ranganathan wrote: On 03/13/2018 03:53 AM, Sankarshan Mukhopadhyay wrote: On Tue, Mar 13, 2018 at 1:05 PM, Pranith Kumar Karampuri wrote: On Tue, Mar 13, 2018 at 7: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. Could you explain the point above further? Is it just the label or the spec/doc that we need merged before the patch is merged? I'll hazard a guess that the intent of the label is to indicate availability of the doc. "Completeness" of code is being defined as including specifications and documentation. As Sankarshan gleaned, spec and doc should be merged/completed before the code is merged, as otherwise smoke will not vote a +1 on the same. I have following suggestion for managing release notes. Let me know if this can be included in automation document. 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. That said, I'll wait for Shyam to be more elaborate on this. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel -- regards Aravinda VK ___ 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 Wed, Mar 14, 2018 at 10:27 AM, Pranith Kumar Karampuri < pkara...@redhat.com> wrote: > > > On Tue, Mar 13, 2018 at 4:26 PM, Pranith Kumar Karampuri < > pkara...@redhat.com> wrote: > >> >> >> On Tue, Mar 13, 2018 at 1:51 PM, Amar Tumballi >> wrote: >> >>> >> >> 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. > > > Could you explain the point above further? Is it just the label or the > spec/doc > that we need merged before the patch is merged? > I'll hazard a guess that the intent of the label is to indicate availability of the doc. "Completeness" of code is being defined as including specifications and documentation. >>> I believe this has originated from maintainers meeting agreements [1] . >>> The proposal to make a spec and documentation mandatory was submitted 3 >>> months back and is documented, and submitted for comment @ >>> https://docs.google.com/document/d/1AFkZmRRDXRxs21GnGauieI >>> yiIiRZ-nTEW8CPi7Gbp3g/edit?usp=sharing >>> >>> >> Thanks! This clears almost all the doubts I had :). >> > > The document above refers to Architects - "Now Architects are approved to > revert a patch which violates by either not having github issue nor bug-id, > or uses a bug-id to get the feature in etc." > > Who are they? What are their responsibilities? > I had heard reference to this role in a Maintainer's meeting too. It was in the context of People meeting up during FAST18 and discussing about the future of Glusterfs. Clarifications on this role is much appreciated. Specifically, * Was there a process to decide on who are they? * If yes, when did this happen? > >> >> >>> The idea is, if the code is going to be released, it should have >>> relevant documentation for users to use it, otherwise, it doesn't matter if >>> the feature is present or not. If the feature is 'default', and there is no >>> documentation required, just mention it, so the flags can be given. Also, >>> if there is no general agreement about the design, it doesn't make sense to >>> merge a feature and then someone has to redo things. >>> >>> For any experimental code, which we want to publish for other developers >>> to test, who doesn't need documentation, we have 'experimental' branch, >>> which should be used for validation. >>> >> >>> [1] - http://lists.gluster.org/pipermail/gluster-devel/2017-Dece >>> mber/054070.html >>> >> >> >> >> -- >> Pranith >> > > > > -- > Pranith > > ___ > 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] [Gluster-Maintainers] Release 4.1: LTM release targeted for end of May
On Tue, Mar 13, 2018 at 4:26 PM, Pranith Kumar Karampuri < pkara...@redhat.com> wrote: > > > On Tue, Mar 13, 2018 at 1:51 PM, Amar Tumballi > wrote: > >> >> >>> >> 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. >>> > >>> > >>> > Could you explain the point above further? Is it just the label or the >>> > spec/doc >>> > that we need merged before the patch is merged? >>> > >>> >>> I'll hazard a guess that the intent of the label is to indicate >>> availability of the doc. "Completeness" of code is being defined as >>> including specifications and documentation. >>> >>> >> I believe this has originated from maintainers meeting agreements [1] . >> The proposal to make a spec and documentation mandatory was submitted 3 >> months back and is documented, and submitted for comment @ >> https://docs.google.com/document/d/1AFkZmRRDXRxs21GnGauieI >> yiIiRZ-nTEW8CPi7Gbp3g/edit?usp=sharing >> >> > Thanks! This clears almost all the doubts I had :). > The document above refers to Architects - "Now Architects are approved to revert a patch which violates by either not having github issue nor bug-id, or uses a bug-id to get the feature in etc." Who are they? What are their responsibilities? > > >> The idea is, if the code is going to be released, it should have relevant >> documentation for users to use it, otherwise, it doesn't matter if the >> feature is present or not. If the feature is 'default', and there is no >> documentation required, just mention it, so the flags can be given. Also, >> if there is no general agreement about the design, it doesn't make sense to >> merge a feature and then someone has to redo things. >> >> For any experimental code, which we want to publish for other developers >> to test, who doesn't need documentation, we have 'experimental' branch, >> which should be used for validation. >> > >> [1] - http://lists.gluster.org/pipermail/gluster-devel/2017-Dece >> mber/054070.html >> > > > > -- > Pranith > -- Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] ./tests/basic/mount-nfs-auth.t spews out warnings
All,
I was trying to debug a regression failure [1]. When I ran test locally on
my laptop, I see some warnings as below:
++ gluster --mode=script --wignore volume get patchy nfs.mount-rmtab
++ xargs dirname
++ awk '/^nfs.mount-rmtab/{print $2}'
dirname: missing operand
Try 'dirname --help' for more information.
+ NFSDIR=
To debug I ran the volume get cmds:
[root@booradley glusterfs]# gluster volume get patchy nfs.mount-rmtab
Option
Value
--
-
volume get option failed. Check the cli/glusterd log file for more details
[root@booradley glusterfs]# gluster volume set patchy nfs.mount-rmtab
testdir
volume set: success
[root@booradley glusterfs]# gluster volume get patchy nfs.mount-rmtab
Option
Value
--
-
nfs.mount-rmtab
testdir
Does this mean the option value is not set properly in the script? Need
your help in debugging this.
@Nigel
I noticed that test is timing out.
*20:28:39* ./tests/basic/mount-nfs-auth.t timed out after 200 seconds
Can this be infra issue where nfs was taking too much time to mount?
[1] https://build.gluster.org/job/centos7-regression/316/console
regards,
Raghavendra
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Announcing Gluster release 4.0.0 (Short Term Maintenance)
The Gluster community celebrates 13 years of development with this latest release, Gluster 4.0. This release enables improved integration with containers, an enhanced user experience, and a next-generation management framework. The 4.0 release helps cloud-native app developers choose Gluster as the default scale-out distributed file system. We’re highlighting some of the announcements, major features and changes here, but our release notes[1] have announcements, expanded major changes and features, and bugs addressed in this release. Major enhancements: - Management GlusterD2 (GD2) is a new management daemon for Gluster-4.0. It is a complete rewrite, with all new internal core frameworks, that make it more scalable, easier to integrate with and has lower maintenance requirements. This replaces GlusterD. A quick start guide [6] is available to get started with GD2. Although GD2 is in tech preview for this release, it is ready to use for forming and managing new clusters. - Monitoring With this release, GlusterFS enables a lightweight method to access internal monitoring information. - Performance There are several enhancements to performance in the disperse translator and in the client side metadata caching layers. - Other enhancements of note This release adds: ability to run Gluster on FIPS compliant systems, ability to force permissions while creating files/directories, and improved consistency in distributed volumes. - Developer related New on-wire protocol version and full type encoding of internal dictionaries on the wire, Global translator to handle per-daemon options, improved translator initialization structure, among a few other improvements, that help streamline development of newer translators. Release packages (or where to get them) are available at [2] and are signed with [3]. The upgrade guide for this release can be found at [4] Related announcements: - As 3.13 was a short term maintenance release, it will reach end of life (EOL) with the release of 4.0.0 [5]. - Releases that receive maintenance updates post 4.0 release are, 3.10, 3.12, 4.0 [5]. - With this release, the CentOS storage SIG will not build server packages for CentOS6. Server packages will be available for CentOS7 only. For ease of migrations, client packages on CentOS6 will be published and maintained, as announced here [7]. References: [1] Release notes: https://docs.gluster.org/en/latest/release-notes/4.0.0.md/ [2] Packages: https://download.gluster.org/pub/gluster/glusterfs/4.0/ [3] Packages signed with: https://download.gluster.org/pub/gluster/glusterfs/4.0/rsa.pub [4] Upgrade guide: https://docs.gluster.org/en/latest/Upgrade-Guide/upgrade_to_4.0/ [5] Release schedule: https://www.gluster.org/release-schedule/ [6] GD2 quick start: https://github.com/gluster/glusterd2/blob/master/doc/quick-start-user-guide.md [7] CentOS Storage SIG CentOS6 support announcement: http://lists.gluster.org/pipermail/gluster-users/2018-January/033212.html ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Cage internal network lock down
Hi, So, I have been working on tightening the internal network of the gluster community cage part of the world, e.g., all the servers in *.int.rht.gluster.org. That's mostly internal infra servers, and newer non cloud builder, but I plan to later also move gerrit/jenkins and various servers. The goal is to reduce IP v4 usage (cause that's limited), and increase security (no direct access to attack, and more difficult to later exploit in case of compromission). That's mostly non impacting people (or I would have asked for maintainance windows) but I just switched all servers in the internal network to use the firewall (masamune.rht.gluster.org) as a gateway rather than IT firewall, so if anything is broken on a *.int.rht.gluster.org server, please tell me and I will look. Everything is in HA, and I have done several tests and reboot during the day without trouble. In fact, more than half of the servers were using that. Right now, the firewall is not yet blocking anything, but that's planned, server by server. Next steps are to prevent direct internet access (so start to use the firewall), and provides both a web proxy and a dns server, so we can log and control what is going on. And move more servers on the internal network (postgresql for example, gerrit/jenkins too), by locking and opening access as needed. -- Michael Scherer Sysadmin, Community Infrastructure and Platform, OSAS signature.asc Description: This is a digitally signed message part ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-Maintainers] Proposal to change the version numbers of Gluster project
On 03/12/2018 02:32 PM, Shyam Ranganathan wrote: > On 03/12/2018 10:34 AM, Atin Mukherjee wrote: >> * >> >> After 4.1, we want to move to either continuous numbering (like >> Fedora), or time based (like ubuntu etc) release numbers. Which >> is the model we pick is not yet finalized. Happy to hear opinions. >> >> >> Not sure how the time based release numbers would make more sense than >> the one which Fedora follows. But before I comment further on this I >> need to first get a clarity on how the op-versions will be managed. I'm >> assuming once we're at GlusterFS 4.1, post that the releases will be >> numbered as GlusterFS5, GlusterFS6 ... So from that perspective, are we >> going to stick to our current numbering scheme of op-version where for >> GlusterFS5 the op-version will be 5? > > Say, yes. > > The question is why tie the op-version to the release number? That > mental model needs to break IMO. > > With current options like, > https://docs.gluster.org/en/latest/Upgrade-Guide/op_version/ it is > easier to determine the op-version of the cluster and what it should be, > and hence this need not be tied to the gluster release version. > > Thoughts? I'm okay with that, but—— Just to play the Devil's Advocate, having an op-version that bears some resemblance to the _version_ number may make it easy/easier to determine what the op-version ought to be. We aren't going to run out of numbers, so there's no reason to be "efficient" here. Let's try to make it easy. (Easy to not make a mistake.) My 2¢ -- Kaleb ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] ./tests/bugs/bug-1110262.t is a bad test susceptible to failures due to race-conditions
All, This test does: 1. mount a volume 2. kill a brick in the volume 3. mkdir (/somedir) In my local tests and in [1], I see that mkdir in step 3 fails because there is no dht-layout on root directory. The reason I think is by the time first lookup on "/" hit dht, a brick was killed as per step 2. This means layout was not healed for "/" and since this is a new volume, no layout is present on it. Note that the first lookup done on "/" by fuse-bridge is not synchronized with parent process of daemonized glusterfs mount completing. IOW, by the time glusterfs cmd executed there is no guarantee that lookup on "/" is complete. So, if step 2 races ahead of fuse_first_lookup on "/", we end up with an invalid dht-layout on "/" resulting in failures. I've sent a patch [2] to fix this race condition. [1] https://build.gluster.org/job/centos7-regression/298/console [2] https://review.gluster.org/#/c/19707/ regards, Raghavendra ___ 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 Tue, Mar 13, 2018 at 1:51 PM, Amar Tumballi wrote: > >> >> >> 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. >> > >> > >> > Could you explain the point above further? Is it just the label or the >> > spec/doc >> > that we need merged before the patch is merged? >> > >> >> I'll hazard a guess that the intent of the label is to indicate >> availability of the doc. "Completeness" of code is being defined as >> including specifications and documentation. >> >> > I believe this has originated from maintainers meeting agreements [1] . > The proposal to make a spec and documentation mandatory was submitted 3 > months back and is documented, and submitted for comment @ > https://docs.google.com/document/d/1AFkZmRRDXRxs21GnGauieIyiIiRZ- > nTEW8CPi7Gbp3g/edit?usp=sharing > > Thanks! This clears almost all the doubts I had :). > The idea is, if the code is going to be released, it should have relevant > documentation for users to use it, otherwise, it doesn't matter if the > feature is present or not. If the feature is 'default', and there is no > documentation required, just mention it, so the flags can be given. Also, > if there is no general agreement about the design, it doesn't make sense to > merge a feature and then someone has to redo things. > > For any experimental code, which we want to publish for other developers > to test, who doesn't need documentation, we have 'experimental' branch, > which should be used for validation. > > [1] - http://lists.gluster.org/pipermail/gluster-devel/2017- > December/054070.html > -- Pranith ___ 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/13/2018 03:53 AM, Sankarshan Mukhopadhyay wrote: > On Tue, Mar 13, 2018 at 1:05 PM, Pranith Kumar Karampuri > wrote: >> >> >> On Tue, Mar 13, 2018 at 7: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. >> >> >> Could you explain the point above further? Is it just the label or the >> spec/doc >> that we need merged before the patch is merged? >> > > I'll hazard a guess that the intent of the label is to indicate > availability of the doc. "Completeness" of code is being defined as > including specifications and documentation. As Sankarshan gleaned, spec and doc should be merged/completed before the code is merged, as otherwise smoke will not vote a +1 on the same. > > That said, I'll wait for Shyam to be more elaborate on this. > ___ 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
> > >> > >> 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. > > > > > > Could you explain the point above further? Is it just the label or the > > spec/doc > > that we need merged before the patch is merged? > > > > I'll hazard a guess that the intent of the label is to indicate > availability of the doc. "Completeness" of code is being defined as > including specifications and documentation. > > I believe this has originated from maintainers meeting agreements [1] . The proposal to make a spec and documentation mandatory was submitted 3 months back and is documented, and submitted for comment @ https://docs.google.com/document/d/1AFkZmRRDXRxs21GnGauieIyiIiRZ-nTEW8CPi7Gbp3g/edit?usp=sharing The idea is, if the code is going to be released, it should have relevant documentation for users to use it, otherwise, it doesn't matter if the feature is present or not. If the feature is 'default', and there is no documentation required, just mention it, so the flags can be given. Also, if there is no general agreement about the design, it doesn't make sense to merge a feature and then someone has to redo things. For any experimental code, which we want to publish for other developers to test, who doesn't need documentation, we have 'experimental' branch, which should be used for validation. [1] - http://lists.gluster.org/pipermail/gluster-devel/2017-December/054070.html ___ 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 Tue, Mar 13, 2018 at 1:05 PM, Pranith Kumar Karampuri wrote: > > > On Tue, Mar 13, 2018 at 7: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. > > > Could you explain the point above further? Is it just the label or the > spec/doc > that we need merged before the patch is merged? > I'll hazard a guess that the intent of the label is to indicate availability of the doc. "Completeness" of code is being defined as including specifications and documentation. That said, I'll wait for Shyam to be more elaborate on this. ___ 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 Tue, Mar 13, 2018 at 7: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. > Could you explain the point above further? Is it just the label or the spec/doc that we need merged before the patch is merged? > > 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? > ___ > maintainers mailing list > maintain...@gluster.org > http://lists.gluster.org/mailman/listinfo/maintainers > -- Pranith ___ 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
> 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
