Re: [Gluster-devel] [Gluster-Maintainers] Release Management Process change - proposal
On Tue, May 10, 2016 at 12:01 AM, Vijay Bellur wrote: > Hi All, > > We are blocked on 3.7.12 owing to this proposal. Appreciate any > feedback on this! > > Thanks, > Vijay > > On Thu, Apr 28, 2016 at 11:58 PM, Vijay Bellur wrote: >> Hi All, >> >> We have encountered a spate of regressions in recent 3.7.x releases. The >> 3.7.x maintainers are facing additional burdens to ensure functional, >> performance and upgrade correctness. I feel component maintainers should own >> these aspects of stability as we own the components and understand our >> components better than anybody else. In order to have more active >> participation from maintainers for every release going forward, I propose >> this process: >> >> 1. All component maintainers will need to provide an explicit ack about the >> content and quality of their respective components before a release is >> tagged. >> >> 2. A release will not be tagged if any component is not acked by a >> maintainer. >> >> 3. Release managers will co-ordinate getting acks from maintainers and >> perform necessary housekeeping (closing bugs etc.). >> >> This is not entirely new and a part of this process has been outlined in the >> Guidelines for Maintainers [1] document. I am inclined to enforce this >> process with more vigor to ensure that we do better on quality & stability. >> >> Thoughts, questions and feedback about the process are very welcome! >> +1 from me. Spreading out the verification duties will help us do better releases. >> Thanks, >> Vijay >> >> [1] >> http://www.gluster.org/community/documentation/index.php/Guidelines_For_Maintainers >> >> > ___ > maintainers mailing list > maintain...@gluster.org > http://www.gluster.org/mailman/listinfo/maintainers ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Release Management Process change - proposal
Hi All, We are blocked on 3.7.12 owing to this proposal. Appreciate any feedback on this! Thanks, Vijay On Thu, Apr 28, 2016 at 11:58 PM, Vijay Bellur wrote: > Hi All, > > We have encountered a spate of regressions in recent 3.7.x releases. The > 3.7.x maintainers are facing additional burdens to ensure functional, > performance and upgrade correctness. I feel component maintainers should own > these aspects of stability as we own the components and understand our > components better than anybody else. In order to have more active > participation from maintainers for every release going forward, I propose > this process: > > 1. All component maintainers will need to provide an explicit ack about the > content and quality of their respective components before a release is > tagged. > > 2. A release will not be tagged if any component is not acked by a > maintainer. > > 3. Release managers will co-ordinate getting acks from maintainers and > perform necessary housekeeping (closing bugs etc.). > > This is not entirely new and a part of this process has been outlined in the > Guidelines for Maintainers [1] document. I am inclined to enforce this > process with more vigor to ensure that we do better on quality & stability. > > Thoughts, questions and feedback about the process are very welcome! > > Thanks, > Vijay > > [1] > http://www.gluster.org/community/documentation/index.php/Guidelines_For_Maintainers > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Show and Tell sessions for Gluster 4.0
On Mon, May 9, 2016 at 2:01 PM, Amye Scavarda wrote: > > > On Sun, May 8, 2016 at 11:50 PM, Raghavendra Talur > wrote: >> >> >> >> On Mon, May 9, 2016 at 11:55 AM, Atin Mukherjee >> wrote: >>> >>> In the view of keeping the visibility of the work completed vs work in >>> progress and getting some fruitful feedback from the community we are >>> thinking of having a hangout/bluejeans session for 30-45 minutes once in >>> every month. The sessions will be concentrating on discussing the work >>> done over the last month and demoing few pieces of Gluster 4.0 projects >>> and what's the expectation for the coming month(s). >>> >>> There are couple of options we have w.r.t scheduling these sessions. >>> >>> 1. We use the weekly community meeting slot once in a month >>> or 2. Have a dedicated separate slot (probably @ 12:00 UTC, last >>> Thursday of each month) >> >> >> I would prefer dedicated time slot. >> >>> >>> >>> I'd request you to vote for any of these two and based on that we can >>> move forward. >>> >>> Thanks, >>> Atin > > > If we use a dedicated timeslot of 12:00 UTC, we'll never be able to have > folks from Pacific weigh in. > I'd suggest more of a rotating timeslot, but we've not had good luck getting > traction around that. > - amye > +1 to this. How about 1500 UTC? That should give time zones where we have more presence (North America, Europe, India) an equal chance to be present. I think accommodating one more meeting in everybody's busy schedules might be tough. We already have 4 bug triage meetings and 4 community meetings in a month. Adding one more might cause us to spread ourselves thin across these meetings. How about not doing a community or bug triage meeting in the same week when we schedule this meeting? We could turn this meeting into a Gluster.next meeting so that everybody who is working on something new in Gluster gets a chance to showcase their work. Thanks! Vijay ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Show and Tell sessions for Gluster 4.0
On Sun, May 8, 2016 at 11:50 PM, Raghavendra Talur wrote: > > > On Mon, May 9, 2016 at 11:55 AM, Atin Mukherjee > wrote: > >> In the view of keeping the visibility of the work completed vs work in >> progress and getting some fruitful feedback from the community we are >> thinking of having a hangout/bluejeans session for 30-45 minutes once in >> every month. The sessions will be concentrating on discussing the work >> done over the last month and demoing few pieces of Gluster 4.0 projects >> and what's the expectation for the coming month(s). >> >> There are couple of options we have w.r.t scheduling these sessions. >> >> 1. We use the weekly community meeting slot once in a month >> or 2. Have a dedicated separate slot (probably @ 12:00 UTC, last >> Thursday of each month) >> > > I would prefer dedicated time slot. > > >> >> I'd request you to vote for any of these two and based on that we can >> move forward. >> >> Thanks, >> Atin >> > If we use a dedicated timeslot of 12:00 UTC, we'll never be able to have folks from Pacific weigh in. I'd suggest more of a rotating timeslot, but we've not had good luck getting traction around that. - amye > ___ >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> http://www.gluster.org/mailman/listinfo/gluster-devel >> > > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel > -- Amye Scavarda | a...@redhat.com | Gluster Community Lead ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Fwd: Gluster Package Matrix, tentative
Resend. N.B. Fedora 24 just entered Beta. The plan is to update GlusterFS to 3.8 in Fedora24 before Fedora24 GA. GlusterFS-3.8 will be the standard version of GlusterFS for the life of Fedora24. Other versions of GlusterFS will be available for Fedora24 on download.gluster.org. N.B. Starting with GlusterFS-3.8, packages for RHEL and CentOS will be available only from the CentOS Storage SIG repos. (They will NOT be available on download.gluster.org, just like we do for GlusterFS package for Ubuntu and SuSE.) Forwarded Message Subject:[Gluster-devel] Gluster Package Matrix, tentative Date: Fri, 1 Apr 2016 09:44:31 -0400 Hi, With the imminent release of 3.8 in a few weeks, here's a summary of the Linux packages that are tentatively planned going forward. Note that 3.5 will reach end-of-life (EOL) when 3.8 is released, and no further releases will be made on the release-3.5 branch. (I haven't included NetBSD or FreeBSD here, only because they're not Linux and we have little control over them.) An X means packages are planned to be in the repository. A — means we have no plans to build the version for the repository. d.g.o means packages will (also) be provided on https://download.gluster.org DNF/YUM means the packages are included in the Fedora updates or updates-testing repos. Â 3.8 3.7 3.6 3.5 CentOS Storage SIG¹ el5 — d.g.o d.g.o d.g.o el6 X X, d.g.oX, d.g.od.g.o el7 X X, d.g.oX, d.g.od.g.o Fedora F22 — d.g.o DNF/YUM d.g.o F23 d.g.o DNF/YUM d.g.o d.g.o F24 DNF/YUM d.g.o d.g.o d.g.o F25 DNF/YUM d.g.o d.g.o d.g.o Ubuntu Launchpad² Precise (12.04 LTS) — X X X Trusty (14.04 LTS) X X X X Wily (15.10)X X X X Xenial (16.04 LTS) X X X — Debian Wheezy (7) — d.g.o d.g.o d.g.o Jessie (8) d.g.o d.g.o d.g.o d.g.o Stretch (9) d.g.o d.g.o d.g.o — SuSE Build System³ OpenSuSE13 X X X X Leap 42.1 X X — — SLES11 — — X X SLES12 X X X — ¹ https://wiki.centos.org/SpecialInterestGroup/Storage ² https://launchpad.net/~gluster ³ https://build.opensuse.org/project/subprojects/home:kkeithleatredhat -- Kaleb ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] git-branch-diff: wrapper script for git to visualize backports
On Thu, May 05, 2016 at 11:25:35PM +0530, Prasanna Kalever wrote:
> Hi Team,
>
> Checkout glusterfs script that is capable of showing your list of commits
> missed (backporting) in other branches (say 3.7.12) w.r.t master
>
> http://review.gluster.org/#/c/14230/
>
>
> This script helps in visualizing backported and missed commits between two
> different branches.
That can be pretty helpful, at least as long as the stable branch(es) do
not diverge too much. Which, will hopefully happen quickly... We really
should not backport much to stable branches.
> While backporting commit to another branch only subject of the patch may
> remain unchanged, all others such as commit message, commit Id, change Id,
> bug Id, will be changed. This script works by taking commit subject as the
> key value for comparing two git branches, which can be local or remote.
Actually, it is strongly recommended to keep the Change-Id the same for
backports. Unfortunately only very few developers stick to our
guidelines for backports, and the Change-Id gets modified :-/
It would be the most suitable way of checking for (missing) backports.
> Help:
>
> $ ./extras/git-branch-diff.py --help
> usage: git-branch-diff.py [-h] [-s SOURCE_BRANCH] -t TARGET_BRANCH
> [-a GIT_AUTHOR] [-p REPO_PATH]
>
> git wrapper to diff local/remote branches
>
> optional arguments:
> -h, --helpshow this help message and exit
> -s SOURCE_BRANCH, --source-branch SOURCE_BRANCH
> source branch name
> -t TARGET_BRANCH, --target-branch TARGET_BRANCH
> target branch name
> -a GIT_AUTHOR, --author GIT_AUTHOR
> default: git config name/email
> -p REPO_PATH, --path REPO_PATH
> show branches diff specific to path
>
>
> Sample usages:
>
> $ ./extras/git-branch-diff.py -t origin/release-3.8
> $ ./extras/git-branch-diff.py -s local_branch -t origin/release-3.7
> $ ./extras/git-branch-diff.py -t origin/release-3.8
> --author="us...@redhat.com"
> $ ./extras/git-branch-diff.py -t origin/release-3.8 --path="xlators/"
>
> $ ./extras/git-branch-diff.py -t origin/release-3.8 --author=""
>
>
>
> Example output:
>
> $ ./extras/git-branch-diff.py -t origin/release-3.8 --path=./rpc
>
>
>
> [ ✔ ] Successfully Backported changes:
> {from: remotes/origin/master to: origin/release-3.8}
>
> glusterd: try to connect on GF_PMAP_PORT_FOREIGN aswell
> rpc: fix gf_process_reserved_ports
> rpc: assign port only if it is unreserved
> server/protocol: option for dynamic authorization of client permissions
> rpc: fix binding brick issue while bind-insecure is enabled
> rpc: By default set allow-insecure, bind-insecure to on
>
>
>
> [ ✖ ] Missing patches in origin/release-3.8:
>
> glusterd: add defence mechanism to avoid brick port clashes
> rpc: define client port range
>
>
>
>
> Note: This script may ignore commits which have altered their commit subjects
> while backporting patches. Also this script doesn't have any intelligence to
> detect squashed commits.
I guess checking the subject of a patch is sufficient for many changes.
More intelligence would be nice, but I doubt it is worth the effort.
Thanks,
Niels
>
>
>
> Thanks,
> --
> Prasanna
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] xlator option setting in gfapi
- Original Message - > From: "Poornima Gurusiddaiah" > To: "Raghavendra Gowdappa" > Cc: "Raghavendra Talur" , "Gluster Devel" > , "Jeff Cody" > , "Rajesh Joseph" > Sent: Monday, May 9, 2016 12:24:44 PM > Subject: Re: xlator option setting in gfapi > > Hi, > > This is what happens when glfs_set_xlator_option is called: > - It updates ctx->cmd_args->xlator_options > - gf_add_cmdline_options (during glusterfs_graph_prepare.. pub_glfs_init) > adds it to xl->options > - glusterfs_graph_unknown_options (during glusterfs_graph_activate.. > pub_glfs_init) checks if the options in xl->options are present or not. If > the option is not present it just logs a warning message. These options are > treated as command line args. > > To report the option as a failure, at the least we can fail glfs_init() failing glfs_init is an acceptable way. Though, there are some thoughts here: 1. We identify xlator (in gf_add_cmdline_options) by providing the name of xlator. This might be a little cumbersome if not wrong. 2. Probably we need to provide a way for the application to know why glfs_init failed (like unknown option, incompatible value for an option, improper xlator configuration etc). This way if some applications want to ignore an error (like ignore an unknown option, which is current behaviour) they can do that. Or providing an option to glfs_init like STRICT_OPTION_CHECKING, IGNORE_UNKNOWN_OPTIONS etc can be passed to fine tune the behavior of glfs_init. 3. If pub_xlator_set_options is specific to mount, what happens if someone else changes a global option? Is the current option remembered and carried forward in new graph too after gfapi receives graph change notification from glusterd? regards, Raghavendra. > > Regards, > Poornima > > - Original Message - > > From: "Raghavendra Gowdappa" > > To: "Poornima Gurusiddaiah" , "Raghavendra Talur" > > > > Cc: "Gluster Devel" , "Jeff Cody" > > , "Rajesh Joseph" > > Sent: Monday, May 9, 2016 8:45:56 AM > > Subject: xlator option setting in gfapi > > > > Hi Poornima/Raghavendra, > > > > This mail is an initiation of a thread to discuss how to make xlator > > options > > setting in gfapi synchronous (so, that caller will know the result) or > > providing a cbk to let the application know about the status. > > > > My very naive attempt of code-reading showed me that > > pub_glfs_set_xlator_option just adds the option to cmd_args.xlator_options. > > Can you please explain how/when these values are communicated to glusterd > > to > > change volfile? From there we can carry forward the conversation. > > > > regards, > > Raghavendra > > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Possible bug in the communications layer ?
I've uploaded a patch for this problem:
http://review.gluster.org/14270
Any review will be very appreciated :)
Thanks,
Xavi
On 09/05/16 12:35, Raghavendra Gowdappa wrote:
- Original Message -
From: "Xavier Hernandez"
To: "Raghavendra Gowdappa"
Cc: "Gluster Devel"
Sent: Monday, May 9, 2016 3:07:16 PM
Subject: Re: [Gluster-devel] Possible bug in the communications layer ?
Hi Raghavendra,
I've finally found the bug. It was obvious but I didn't see it.
Same here :).
1561 case SP_STATE_ACCEPTED_SUCCESS_REPLY_INIT:
1562 default_read_size = xdr_sizeof ((xdrproc_t)
xdr_gfs3_read_rsp,
1563 &read_rsp);
1564
1565 proghdr_buf = frag->fragcurrent;
1566
1567 __socket_proto_init_pending (priv,
default_read_size);
1568
1569 frag->call_body.reply.accepted_success_state
1570 = SP_STATE_READING_PROC_HEADER;
1571
1572 /* fall through */
1573
1574 case SP_STATE_READING_PROC_HEADER:
1575 __socket_proto_read (priv, ret);
1576
1577 gf_trace_add("xdrmem_create", default_read_size,
(uintptr_t)proghdr_buf);
1578 /* there can be 'xdata' in read response, figure
it out */
1579 xdrmem_create (&xdr, proghdr_buf, default_read_size,
1580XDR_DECODE);
1581
1582 /* This will fail if there is xdata sent from
server, if not,
1583well and good, we don't need to worry about */
1584 xdr_gfs3_read_rsp (&xdr, &read_rsp);
1585
1586 free (read_rsp.xdata.xdata_val);
1587
1588 /* need to round off to proper roof (%4), as XDR
packing pads
1589the end of opaque object with '0' */
1590 size = roof (read_rsp.xdata.xdata_len, 4);
1591
1592 if (!size) {
1593 frag->call_body.reply.accepted_success_state
1594 = SP_STATE_READ_PROC_OPAQUE;
1595 goto read_proc_opaque;
1596 }
1597
1598 __socket_proto_init_pending (priv, size);
1599
1600 frag->call_body.reply.accepted_success_state
1601 = SP_STATE_READING_PROC_OPAQUE;
The main problem here is that we are using two local variables
(proghdr_buf and default_read_size) in two distinct states that might be
called at different times.
The particular case that is failing is the following:
1. In state SP_STATE_ACCEPTED_SUCCESS_REPLY_INIT, everything is prepared
to read 116 bytes. default_read_size is set to 116 and proghdr_buf
points to the buffer where data will be written.
2. In state SP_STATE_READING_PROC_HEADER, a partial read of 88 bytes is
done. At this point the function returns and proghdr_buf and
default_read_size are lost.
3. When more data is available, this function is called again and it
starts executing at state SP_STATE_READING_PROC_HEADER.
4. The remaining 28 bytes are read.
5. When it checks the buffer and tries to decode it to see if there's
xdata present, it uses the default values of proghdr_buf and
default_read_size, that are 0. This causes the decode to leave
read_rsp.xdata.xdata_len set to 0.
6. The program interprets that xdata_len being 0 means that there's no
xdata, so it continues reading the remaining of the RPC packet into the
payload buffer.
If you want, I can send a patch for this.
Yes. That would be helpful. The analysis is correct and moving initialization
of prog_hdrbuf to line 1578 will fix the issue. If you are too busy, please let
me know and I can patch it up too :).
Thanks for debugging the issue :).
regards,
Raghavendra.
Xavi
On 05/05/16 10:21, Xavier Hernandez wrote:
I've undone all changes and now I'm unable to reproduce the problem, so
the modification I did is probably incorrect and not the root cause, as
you described.
I'll continue investigating...
Xavi
On 04/05/16 15:01, Xavier Hernandez wrote:
On 04/05/16 14:47, Raghavendra Gowdappa wrote:
- Original Message -
From: "Xavier Hernandez"
To: "Raghavendra Gowdappa"
Cc: "Gluster Devel"
Sent: Wednesday, May 4, 2016 5:37:56 PM
Subject: Re: [Gluster-devel] Possible bug in the communications layer ?
I think I've found the problem.
1567 case SP_STATE_READING_PROC_HEADER:
1568 __socket_proto_read (priv, ret);
1569
1570 /* there can be 'xdata' in read response, figure
it out */
1571 xdrmem_create (&xdr, proghdr_buf,
default_read_size,
1572XDR_DECODE);
1573
1574 /* This will fail if there is xdata sent from
server, if not,
1575well and good, we don't need to worry
about */
1576 xdr_gfs3_read_r
Re: [Gluster-devel] snapshot tests cause coredump in dmeventd
On Wed, May 4, 2016 at 7:19 PM, Michael Scherer wrote: > Le mercredi 04 mai 2016 à 10:42 +0530, Rajesh Joseph a écrit : > > On Mon, May 2, 2016 at 3:04 AM, Niels de Vos wrote: > > > > > It seems that a snaphot regression test managed to trigger a core dump > > > in dmeventd. Because our regression tests check for cores, the test was > > > marked as a failure (mostly a 'good' thing). > > > > > > I'd appreciate it if one of the developers of snapshot can have a look > > > at the core from dmeventd and maybe check with the LVM developers if > > > this is a known bug. The core can be downloaded from the bottom of this > > > link: > > > > > > > https://build.gluster.org/job/rackspace-regression-2GB-triggered/20315/console > > > > > > > > The slave machine is not accessible therefore could not download the core > > file. Is it > > possible to get access to this machine? > > I opened the firewall for that port, didn't see it was not before. > So you can now download the tarball. > > I will add it to the automation to open the others too. > Thanks Michael for looking into this. The machine is still not accessible. Thanks & Regards, Rajesh > -- > Michael Scherer > Sysadmin, Community Infrastructure and Platform, OSAS > > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Possible bug in the communications layer ?
- Original Message -
> From: "Xavier Hernandez"
> To: "Raghavendra Gowdappa"
> Cc: "Gluster Devel"
> Sent: Monday, May 9, 2016 3:07:16 PM
> Subject: Re: [Gluster-devel] Possible bug in the communications layer ?
>
> Hi Raghavendra,
>
> I've finally found the bug. It was obvious but I didn't see it.
Same here :).
>
> 1561 case SP_STATE_ACCEPTED_SUCCESS_REPLY_INIT:
> 1562 default_read_size = xdr_sizeof ((xdrproc_t)
> xdr_gfs3_read_rsp,
> 1563 &read_rsp);
> 1564
> 1565 proghdr_buf = frag->fragcurrent;
> 1566
> 1567 __socket_proto_init_pending (priv,
> default_read_size);
> 1568
> 1569 frag->call_body.reply.accepted_success_state
> 1570 = SP_STATE_READING_PROC_HEADER;
> 1571
> 1572 /* fall through */
> 1573
> 1574 case SP_STATE_READING_PROC_HEADER:
> 1575 __socket_proto_read (priv, ret);
> 1576
> 1577 gf_trace_add("xdrmem_create", default_read_size,
> (uintptr_t)proghdr_buf);
> 1578 /* there can be 'xdata' in read response, figure
> it out */
> 1579 xdrmem_create (&xdr, proghdr_buf, default_read_size,
> 1580XDR_DECODE);
> 1581
> 1582 /* This will fail if there is xdata sent from
> server, if not,
> 1583well and good, we don't need to worry about */
> 1584 xdr_gfs3_read_rsp (&xdr, &read_rsp);
> 1585
> 1586 free (read_rsp.xdata.xdata_val);
> 1587
> 1588 /* need to round off to proper roof (%4), as XDR
> packing pads
> 1589the end of opaque object with '0' */
> 1590 size = roof (read_rsp.xdata.xdata_len, 4);
> 1591
> 1592 if (!size) {
> 1593 frag->call_body.reply.accepted_success_state
> 1594 = SP_STATE_READ_PROC_OPAQUE;
> 1595 goto read_proc_opaque;
> 1596 }
> 1597
> 1598 __socket_proto_init_pending (priv, size);
> 1599
> 1600 frag->call_body.reply.accepted_success_state
> 1601 = SP_STATE_READING_PROC_OPAQUE;
>
> The main problem here is that we are using two local variables
> (proghdr_buf and default_read_size) in two distinct states that might be
> called at different times.
>
> The particular case that is failing is the following:
>
> 1. In state SP_STATE_ACCEPTED_SUCCESS_REPLY_INIT, everything is prepared
> to read 116 bytes. default_read_size is set to 116 and proghdr_buf
> points to the buffer where data will be written.
>
> 2. In state SP_STATE_READING_PROC_HEADER, a partial read of 88 bytes is
> done. At this point the function returns and proghdr_buf and
> default_read_size are lost.
>
> 3. When more data is available, this function is called again and it
> starts executing at state SP_STATE_READING_PROC_HEADER.
>
> 4. The remaining 28 bytes are read.
>
> 5. When it checks the buffer and tries to decode it to see if there's
> xdata present, it uses the default values of proghdr_buf and
> default_read_size, that are 0. This causes the decode to leave
> read_rsp.xdata.xdata_len set to 0.
>
> 6. The program interprets that xdata_len being 0 means that there's no
> xdata, so it continues reading the remaining of the RPC packet into the
> payload buffer.
>
> If you want, I can send a patch for this.
Yes. That would be helpful. The analysis is correct and moving initialization
of prog_hdrbuf to line 1578 will fix the issue. If you are too busy, please let
me know and I can patch it up too :).
Thanks for debugging the issue :).
regards,
Raghavendra.
>
> Xavi
>
> On 05/05/16 10:21, Xavier Hernandez wrote:
> > I've undone all changes and now I'm unable to reproduce the problem, so
> > the modification I did is probably incorrect and not the root cause, as
> > you described.
> >
> > I'll continue investigating...
> >
> > Xavi
> >
> > On 04/05/16 15:01, Xavier Hernandez wrote:
> >> On 04/05/16 14:47, Raghavendra Gowdappa wrote:
> >>>
> >>>
> >>> - Original Message -
> From: "Xavier Hernandez"
> To: "Raghavendra Gowdappa"
> Cc: "Gluster Devel"
> Sent: Wednesday, May 4, 2016 5:37:56 PM
> Subject: Re: [Gluster-devel] Possible bug in the communications layer ?
>
> I think I've found the problem.
>
> 1567 case SP_STATE_READING_PROC_HEADER:
> 1568 __socket_proto_read (priv, ret);
> 1569
> 1570 /* there can be 'xdata' in read response, figure
> it out */
> 1571 xdrmem_create (&xdr, proghdr_buf,
> default_read_size,
> 1572XDR_DECODE);
> 1573
> 1574 /
Re: [Gluster-devel] Possible bug in the communications layer ?
Hi Raghavendra,
I've finally found the bug. It was obvious but I didn't see it.
1561 case SP_STATE_ACCEPTED_SUCCESS_REPLY_INIT:
1562 default_read_size = xdr_sizeof ((xdrproc_t)
xdr_gfs3_read_rsp,
1563 &read_rsp);
1564
1565 proghdr_buf = frag->fragcurrent;
1566
1567 __socket_proto_init_pending (priv,
default_read_size);
1568
1569 frag->call_body.reply.accepted_success_state
1570 = SP_STATE_READING_PROC_HEADER;
1571
1572 /* fall through */
1573
1574 case SP_STATE_READING_PROC_HEADER:
1575 __socket_proto_read (priv, ret);
1576
1577 gf_trace_add("xdrmem_create", default_read_size,
(uintptr_t)proghdr_buf);
1578 /* there can be 'xdata' in read response, figure
it out */
1579 xdrmem_create (&xdr, proghdr_buf, default_read_size,
1580XDR_DECODE);
1581
1582 /* This will fail if there is xdata sent from
server, if not,
1583well and good, we don't need to worry about */
1584 xdr_gfs3_read_rsp (&xdr, &read_rsp);
1585
1586 free (read_rsp.xdata.xdata_val);
1587
1588 /* need to round off to proper roof (%4), as XDR
packing pads
1589the end of opaque object with '0' */
1590 size = roof (read_rsp.xdata.xdata_len, 4);
1591
1592 if (!size) {
1593 frag->call_body.reply.accepted_success_state
1594 = SP_STATE_READ_PROC_OPAQUE;
1595 goto read_proc_opaque;
1596 }
1597
1598 __socket_proto_init_pending (priv, size);
1599
1600 frag->call_body.reply.accepted_success_state
1601 = SP_STATE_READING_PROC_OPAQUE;
The main problem here is that we are using two local variables
(proghdr_buf and default_read_size) in two distinct states that might be
called at different times.
The particular case that is failing is the following:
1. In state SP_STATE_ACCEPTED_SUCCESS_REPLY_INIT, everything is prepared
to read 116 bytes. default_read_size is set to 116 and proghdr_buf
points to the buffer where data will be written.
2. In state SP_STATE_READING_PROC_HEADER, a partial read of 88 bytes is
done. At this point the function returns and proghdr_buf and
default_read_size are lost.
3. When more data is available, this function is called again and it
starts executing at state SP_STATE_READING_PROC_HEADER.
4. The remaining 28 bytes are read.
5. When it checks the buffer and tries to decode it to see if there's
xdata present, it uses the default values of proghdr_buf and
default_read_size, that are 0. This causes the decode to leave
read_rsp.xdata.xdata_len set to 0.
6. The program interprets that xdata_len being 0 means that there's no
xdata, so it continues reading the remaining of the RPC packet into the
payload buffer.
If you want, I can send a patch for this.
Xavi
On 05/05/16 10:21, Xavier Hernandez wrote:
I've undone all changes and now I'm unable to reproduce the problem, so
the modification I did is probably incorrect and not the root cause, as
you described.
I'll continue investigating...
Xavi
On 04/05/16 15:01, Xavier Hernandez wrote:
On 04/05/16 14:47, Raghavendra Gowdappa wrote:
- Original Message -
From: "Xavier Hernandez"
To: "Raghavendra Gowdappa"
Cc: "Gluster Devel"
Sent: Wednesday, May 4, 2016 5:37:56 PM
Subject: Re: [Gluster-devel] Possible bug in the communications layer ?
I think I've found the problem.
1567 case SP_STATE_READING_PROC_HEADER:
1568 __socket_proto_read (priv, ret);
1569
1570 /* there can be 'xdata' in read response, figure
it out */
1571 xdrmem_create (&xdr, proghdr_buf,
default_read_size,
1572XDR_DECODE);
1573
1574 /* This will fail if there is xdata sent from
server, if not,
1575well and good, we don't need to worry
about */
1576 xdr_gfs3_read_rsp (&xdr, &read_rsp);
1577
1578 free (read_rsp.xdata.xdata_val);
1579
1580 /* need to round off to proper roof (%4), as XDR
packing pads
1581the end of opaque object with '0' */
1582 size = roof (read_rsp.xdata.xdata_len, 4);
1583
1584 if (!size) {
1585
frag->call_body.reply.accepted_success_state
1586 = SP_STATE_READ_PROC_OPAQUE;
1587 goto read_proc_opaque;
1588 }
1589
1590 __socket_proto_init_pending (priv, size);
1591
1592 frag->call_body.reply.accepted_succ
[Gluster-devel] MKDIR_P and mkdir_p
On Mon, May 09, 2016 at 12:02:56PM +0530, Milind Changire wrote:
> Niels, Kaleb,
> With Niels' commit 4ac2ff18db62db192c49affd8591e846c810667a
> reverting Manu's commit 1fbcecb72ef3525823536b640d244d1e5127a37f
> on upstream master, and w.r.t. Kaleb's patch
> http://review.gluster.org/14243
> with Niels' comment to move the lines to the Makefile, it looks
> like the Makefile.am in tools/glusterfind/ is already coded to do
> what Kaleb has proposed in the patch.
>
> If you look at the upstream SPEC file there's been an %install
> entry added to create a %{_sharedstatedir/glusterd/glusterfind/.keys
> directory. But looking at tools/glusterfind/Makefile.am, this looks
> like an already solved problem. However, I think this came by due to
> the MKDIR_P/mkdir_p not working on some platforms and hence leading to
> the SPEC file kludges.
>
> How do we get out of this MKDIR_P vs mkdir_p issue once and for all
> for all the platforms? This is especially painful during downstream
> packaging.
Current upstream only seems to use mkdir_p in Makefile.am files:
$ git grep MKDIR_P -- '*/Makefile.am'
$ git grep mkdir_p -- '*/Makefile.am'
cli/src/Makefile.am:$(mkdir_p)
$(DESTDIR)$(localstatedir)/run/gluster
extras/Makefile.am: $(mkdir_p) $(DESTDIR)$(tmpfilesdir); \
extras/Makefile.am: $(mkdir_p) $(DESTDIR)$(GLUSTERD_WORKDIR)/groups
extras/init.d/Makefile.am: $(mkdir_p)
$(DESTDIR)$(INIT_DIR); \
extras/init.d/Makefile.am: $(mkdir_p) $(DESTDIR)$(LAUNCHD_DIR)
extras/systemd/Makefile.am: $(mkdir_p)
$(DESTDIR)$(SYSTEMD_DIR); \
tools/glusterfind/Makefile.am: $(mkdir_p)
$(DESTDIR)$(GLUSTERD_WORKDIR)/glusterfind/.keys
tools/glusterfind/Makefile.am: $(mkdir_p)
$(DESTDIR)$(GLUSTERD_WORKDIR)/hooks/1/delete/post/
xlators/mgmt/glusterd/src/Makefile.am: $(mkdir_p)
$(DESTDIR)$(GLUSTERD_WORKDIR)
This might, or mught not be correct. Because you found the commit where
Manu mentioned that mkdir_p is not available on all distributions, you
may want to get his opinion too? Just send the email to the devel list
and we can discuss it there.
--
Milind
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] git-branch-diff: wrapper script for git to visualize backports
Hi all,
checkout http://review.gluster.org/14230
I have added more cool features in patch set 2 to meet both developers
as well as release maintainers expectations.
Thanks,
--
Prasanna
On Fri, May 6, 2016 at 1:22 PM, Prasanna Kalever wrote:
> On Fri, May 6, 2016 at 12:03 PM, Atin Mukherjee wrote:
>>
>>
>> On 05/05/2016 11:25 PM, Prasanna Kalever wrote:
>>> Hi Team,
>>>
>>> Checkout glusterfs script that is capable of showing your list of commits
>>> missed (backporting) in other branches (say 3.7.12) w.r.t master
>>>
>>> http://review.gluster.org/#/c/14230/
>>>
>>>
>>> This script helps in visualizing backported and missed commits between two
>>> different branches.
>>>
>>> While backporting commit to another branch only subject of the patch may
>>> remain unchanged, all others such as commit message, commit Id, change Id,
>>> bug Id, will be changed. This script works by taking commit subject as the
>>> key value for comparing two git branches, which can be local or remote.
>> Nice work!! This will be really helpful in situation like now where we
>> have to backport almost all our fixes from mainline to 3.7 & 3.8 branches.
>>
>> I'd also request you to send a report on the patches missing in 3.8
>> branch and send a reminder to all the developers asking for the backports.
>>
>> Also is there a way to limit the comparison? For an example I may be
>> interested in seeing the delta between mainline and last 3.7 release
>> i.e. 3.7.11 and do not want to compare the whole 3.7 branch?
>
> Thank you Atin, that a good Idea.
> That can be done using git tags, but I need to some more investigation
> with the git :)
>
> I would like to here more from the developers to make this tool better.
>
> --
> Prasanna
>>
>> ~Atin
>>>
>>>
>>>
>>> Help:
>>>
>>> $ ./extras/git-branch-diff.py --help
>>> usage: git-branch-diff.py [-h] [-s SOURCE_BRANCH] -t TARGET_BRANCH
>>> [-a GIT_AUTHOR] [-p REPO_PATH]
>>>
>>> git wrapper to diff local/remote branches
>>>
>>> optional arguments:
>>> -h, --helpshow this help message and exit
>>> -s SOURCE_BRANCH, --source-branch SOURCE_BRANCH
>>> source branch name
>>> -t TARGET_BRANCH, --target-branch TARGET_BRANCH
>>> target branch name
>>> -a GIT_AUTHOR, --author GIT_AUTHOR
>>> default: git config name/email
>>> -p REPO_PATH, --path REPO_PATH
>>> show branches diff specific to path
>>>
>>>
>>> Sample usages:
>>>
>>> $ ./extras/git-branch-diff.py -t origin/release-3.8
>>> $ ./extras/git-branch-diff.py -s local_branch -t origin/release-3.7
>>> $ ./extras/git-branch-diff.py -t origin/release-3.8
>>> --author="us...@redhat.com"
>>> $ ./extras/git-branch-diff.py -t origin/release-3.8 --path="xlators/"
>>>
>>> $ ./extras/git-branch-diff.py -t origin/release-3.8 --author=""
>>>
>>>
>>>
>>> Example output:
>>>
>>> $ ./extras/git-branch-diff.py -t origin/release-3.8 --path=./rpc
>>>
>>>
>>>
>>> [ ✔ ] Successfully Backported changes:
>>> {from: remotes/origin/master to: origin/release-3.8}
>>>
>>> glusterd: try to connect on GF_PMAP_PORT_FOREIGN aswell
>>> rpc: fix gf_process_reserved_ports
>>> rpc: assign port only if it is unreserved
>>> server/protocol: option for dynamic authorization of client permissions
>>> rpc: fix binding brick issue while bind-insecure is enabled
>>> rpc: By default set allow-insecure, bind-insecure to on
>>>
>>>
>>>
>>> [ ✖ ] Missing patches in origin/release-3.8:
>>>
>>> glusterd: add defence mechanism to avoid brick port clashes
>>> rpc: define client port range
>>>
>>>
>>>
>>>
>>> Note: This script may ignore commits which have altered their commit
>>> subjects
>>> while backporting patches. Also this script doesn't have any intelligence to
>>> detect squashed commits.
>>>
>>>
>>>
>>> Thanks,
>>> --
>>> Prasanna
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] tests/performance/open-behind.t fails on NetBSD
On Sun, May 8, 2016 at 10:33 PM, Emmanuel Dreyfus wrote: > Joseph Fernandes wrote: > > > ./tests/performance/open-behind.t is failing continuously on 3.7.11 > > This is the fate of non enforced tests. It may be a good idea to > invetigate it: perhaps NetBSD gets a reliable failure for a rare bug > that is not NetBSD specific. We already saw such situations. > Emmanuel is right. It might be a valid failure that is only reproducible on NetBSD. I found that a bug was already filed on master. I have cloned it for 3.7. Bug:https://bugzilla.redhat.com/show_bug.cgi?id=1334204 Patch to mark test as bad in 3.7: http://review.gluster.org/14256 Thanks, Raghavendra Talur > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > m...@netbsd.org > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
