<div dir="ltr"><div><div>Hi,</div><div><br></div><div>I have done some basic testing specific to SSL component on tar(<a href="http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.9.0rc2.tar.gz" style="white-space:pre-wrap">http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.9.0rc2.tar.gz</a>).</div><div><br></div><div>1) After enable SSL(io and mgmt encryption ) mount is working(for distributed/replicated) and able to transfer data on volume.</div><div>2) reconnection is working after disconnect.</div><div><br></div><div>Regards</div><div>Mohit Agrawal</div></div><div><br></div><div><br></div><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 27, 2016 at 8:30 AM, <span dir="ltr"><<a href="mailto:gluster-devel-request@gluster.org" target="_blank">gluster-devel-request@<wbr>gluster.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Send Gluster-devel mailing list submissions to<br>
<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman<wbr>/listinfo/gluster-devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:gluster-devel-request@gluster.org" target="_blank">gluster-devel-request@gluster.<wbr>org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:gluster-devel-owner@gluster.org" target="_blank">gluster-devel-owner@gluster.or<wbr>g</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Gluster-devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Memory management and friends (Oleksandr Natalenko)<br>
2. Re: Gluster Test Thursday - Release 3.9 (Aravinda)<br>
3. Re: Multiplexing status, October 26 (Jeff Darcy)<br>
4. Re: [Gluster-Maintainers] Gluster Test Thursday - Release 3.9<br>
(Niels de Vos)<br>
5. Re: [Gluster-Maintainers] glusterfs-3.9.0rc2 released<br>
(Kaleb S. KEITHLEY)<br>
6. automating straightforward backports (Pranith Kumar Karampuri)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Wed, 26 Oct 2016 16:27:40 +0200<br>
From: Oleksandr Natalenko <<a href="mailto:oleksandr@natalenko.name" target="_blank">oleksandr@natalenko.name</a>><br>
To: Gluster Devel <<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>><br>
Subject: [Gluster-devel] Memory management and friends<br>
Message-ID: <<a href="mailto:1c49cb1391aaeda5b3fb129ccbf66c83@natalenko.name" target="_blank">1c49cb1391aaeda5b3fb129ccbf66<wbr>c83@natalenko.name</a>><br>
Content-Type: text/plain; charset=UTF-8; format=flowed<br>
<br>
Hello.<br>
<br>
As a result of today's community meeting I start dedicated ML thread for<br>
gathering memory management issues together to make it possible to<br>
summarize them and construct some plan what to do next.<br>
<br>
Very important notice: I'm not the active GlusterFS developer, but<br>
gained excessive experience with GlusterFS in the past at previous work,<br>
and the main issue that was chasing me all the time was memory leaking.<br>
Consider this as a request for action from GlusterFS customer,<br>
apparently approved by Kaushal and Amye during last meeting :).<br>
<br>
So, here go key points.<br>
<br>
1) Almost all nasty and obvious memory leaks have been successfully<br>
fixed during the last year, and that allowed me to run GlusterFS in<br>
production at previous work for almost all types of workload except one<br>
? dovecot mail storage. The specific of this workload is that it<br>
involved huge amount of files, and I assume this to be kinda of edge<br>
case unhiding some dark corners of GlusterFS memory management. I was<br>
able to provide Nithya with Valgrind+Massif memory profiling results and<br>
test case, and that helped her to prepare at least 1 extra fix (and more<br>
to come AFAIK), which has some deal with readdirp-related code.<br>
Nevertheless, it is reported that this is not the major source of<br>
leaking. Nithya suspect that memory gets fragmented heavily due to lots<br>
of small allocations, and memory pools cannot cope with this kind of<br>
fragmentation under constant load.<br>
<br>
Related BZs:<br>
<br>
* <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1369364" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/sh<wbr>ow_bug.cgi?id=1369364</a><br>
* <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1380249" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/sh<wbr>ow_bug.cgi?id=1380249</a><br>
<br>
People involved:<br>
<br>
* nbalacha, could you please provide more info on your findings?<br>
<br>
2) Meanwhile, Jeff goes on with brick multiplexing feature, facing some<br>
issue with memory management too and blaming memory pools for that.<br>
<br>
Related ML email:<br>
<br>
*<br>
<a href="http://www.gluster.org/pipermail/gluster-devel/2016-October/051118.html" rel="noreferrer" target="_blank">http://www.gluster.org/piperma<wbr>il/gluster-devel/2016-October/<wbr>051118.html</a><br>
*<br>
<a href="http://www.gluster.org/pipermail/gluster-devel/2016-October/051160.html" rel="noreferrer" target="_blank">http://www.gluster.org/piperma<wbr>il/gluster-devel/2016-October/<wbr>051160.html</a><br>
<br>
People involved:<br>
<br>
* jdarcy, have you discussed this outside of ML? It seems your email<br>
didn't get proper attention.<br>
<br>
3) We had brief discussion with obnox and anoopcs on #gluster-meeting<br>
and #gluster-dev regarding jemalloc and talloc. obnox believes that we<br>
may use both, jemalloc for substituting malloc/free, talloc for<br>
rewriting memory management for GlusterFS properly.<br>
<br>
Related logs:<br>
<br>
*<br>
<a href="https://botbot.me/freenode/gluster-dev/2016-10-26/?msg=75501394&page=2" rel="noreferrer" target="_blank">https://botbot.me/freenode/glu<wbr>ster-dev/2016-10-26/?msg=75501<wbr>394&page=2</a><br>
<br>
People involved:<br>
<br>
* obnox, could you share your ideas on this?<br>
<br>
To summarize:<br>
<br>
1) we need key devs involved in memory management to share their ideas;<br>
2) using production-proven memory allocators and memory pools<br>
implementation is desired;<br>
3) someone should manage the workflow of reconstructing memory<br>
management.<br>
<br>
Feel free to add anything I've missed.<br>
<br>
Regards,<br>
Oleksandr<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 26 Oct 2016 20:04:54 +0530<br>
From: Aravinda <<a href="mailto:avishwan@redhat.com" target="_blank">avishwan@redhat.com</a>><br>
To: Gluster Devel <<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>>, GlusterFS Maintainers<br>
<<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a>><br>
Subject: Re: [Gluster-devel] Gluster Test Thursday - Release 3.9<br>
Message-ID: <<a href="mailto:23162ff6-3f9e-957b-fb8c-7ad9924e1434@redhat.com" target="_blank">23162ff6-3f9e-957b-fb8c-7ad99<wbr>24e1434@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Gluster 3.9.0rc2 tarball is available here<br>
<a href="http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.9.0rc2.tar.gz" rel="noreferrer" target="_blank">http://bits.gluster.org/pub/gl<wbr>uster/glusterfs/src/glusterfs-<wbr>3.9.0rc2.tar.gz</a><br>
<br>
regards<br>
Aravinda<br>
<br>
On Tuesday 25 October 2016 04:12 PM, Aravinda wrote:<br>
> Hi,<br>
><br>
> Since Automated test framework for Gluster is in progress, we need<br>
> help from Maintainers and developers to test the features and bug<br>
> fixes to release Gluster 3.9.<br>
><br>
> In last maintainers meeting Shyam shared an idea about having a Test<br>
> day to accelerate the testing and release.<br>
><br>
> Please participate in testing your component(s) on Oct 27, 2016. We<br>
> will prepare the rc2 build by tomorrow and share the details before<br>
> Test day.<br>
><br>
> RC1 Link:<br>
> <a href="http://www.gluster.org/pipermail/maintainers/2016-September/001442.html" rel="noreferrer" target="_blank">http://www.gluster.org/piperma<wbr>il/maintainers/2016-September/<wbr>001442.html</a><br>
> Release Checklist:<br>
> <a href="https://public.pad.fsfe.org/p/gluster-component-release-checklist" rel="noreferrer" target="_blank">https://public.pad.fsfe.org/p/<wbr>gluster-component-release-chec<wbr>klist</a><br>
><br>
><br>
> Thanks and Regards<br>
> Aravinda and Pranith<br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 26 Oct 2016 10:58:25 -0400 (EDT)<br>
From: Jeff Darcy <<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>><br>
To: Gluster Devel <<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>><br>
Subject: Re: [Gluster-devel] Multiplexing status, October 26<br>
Message-ID:<br>
<<a href="mailto:1756619054.12954195.1477493905921.JavaMail.zimbra@redhat.com" target="_blank">1756619054.12954195.147749390<wbr>5921.JavaMail.zimbra@redhat.<wbr>com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Here are some of the numbers. Note that these are *without* multiplexing, which is where these changes are really most beneficial, because I wanted to measure the effect of this patch on its own. Also, perf-test.sh is a truly awful test. For one thing it's entirely single-threaded, which limits is usefulness in general and reduces that usefulness to near (or below) zero for any change focused on higher levels of parallelism. Also, it's very unbalanced, testing certain operations for over twenty minutes and others for mere fractions of a second. Lastly, it takes way too long to run - over two hours on my machines. Tying up a test machine for a whole day running tests before and after a change three times each (as I was asked to do) is not a good use of resources. What I actually ran is a reduced and rebalanced version, which takes about fifteen minutes. I also ran my own test that I developed for multiplexing - twenty volumes/mounts, eighty bricks, a hundred client I/O<br>
threads creating/writing/deleting files. It drives load literally a hundred times higher, and really tests scalability.<br>
<br>
Full results are below. To summarize, the patch seems to improve performance on perf-test on 9/17 tests. Overall it's either 0.6% slower or 2.3% faster depending on how you combine the per-test results. On my own loadtest it's 1.9% slower. In other words, for the *non-multiplexing* case (which will soon be obsolete), we're either below the measurement-error threshold or truly slower by a tiny amount. With multiplexing and other multiplexing-related changes (e.g. <a href="http://review.gluster.org/#/c/15645/" rel="noreferrer" target="_blank">http://review.gluster.org/#/c/<wbr>15645/</a>) we'll be way ahead on any realistic test.<br>
<br>
*** PERF-TEST WITHOUT PATCH<br>
<br>
Testname Time<br>
emptyfiles_create 49.57<br>
emptyfiles_delete 22.05<br>
smallfiles_create 98.70<br>
smallfiles_rewrite 94.14<br>
smallfiles_read 28.01<br>
smallfiles_reread 10.76<br>
smallfiles_delete 23.25<br>
largefile_create 26.58<br>
largefile_rewrite 59.18<br>
largefile_read 20.43<br>
largefile_reread 1.35<br>
largefile_delete 0.59<br>
directory_crawl_create 126.85<br>
directory_crawl 8.78<br>
directory_recrawl 6.81<br>
metadata_modify 132.44<br>
directory_crawl_delete 53.75<br>
<br>
real 13m57.254s<br>
user 0m16.929s<br>
sys 0m44.114s<br>
<br>
*** LOADTEST WITHOUT PATCH<br>
<br>
real 5m15.483s<br>
user 0m0.724s<br>
sys 0m16.686s<br>
<br>
*** PERF-TEST WITH PATCH<br>
<br>
Testname Time<br>
emptyfiles_create 48.73 - 1.7%<br>
emptyfiles_delete 23.41 + 6.2%<br>
smallfiles_create 92.06 - 6.7%<br>
smallfiles_rewrite 86.33 - 8.3%<br>
smallfiles_read 28.48 + 1.7%<br>
smallfiles_reread 11.56 + 7.4%<br>
smallfiles_delete 22.99 - 1.1%<br>
largefile_create 22.76 - 2.1%<br>
largefile_rewrite 60.94 + 3.0%<br>
largefile_read 18.67 - 8.6%<br>
largefile_reread 1.52 + 12.6%<br>
largefile_delete 0.55 - 6.8%<br>
directory_crawl_create 125.47 - 1.1%<br>
directory_crawl 10.19 + 16.1%<br>
directory_recrawl 6.58 - 3.4%<br>
metadata_modify 125.29 - 5.4%<br>
directory_crawl_delete 55.63 + 3.5%<br>
+ 0.6%<br>
<br>
real 13m38.115s -2.3%<br>
user 0m16.197s<br>
sys 0m43.057s<br>
<br>
*** LOADTEST WITH PATCH<br>
<br>
real 5m21.479s + 1.9%<br>
user 0m0.685s<br>
sys 0m17.260s<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 26 Oct 2016 20:13:15 +0200<br>
From: Niels de Vos <<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>><br>
To: "Kaleb S. KEITHLEY" <<a href="mailto:kkeithle@redhat.com" target="_blank">kkeithle@redhat.com</a>><br>
Cc: GlusterFS Maintainers <<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a>>, Gluster Devel<br>
<<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>><br>
Subject: Re: [Gluster-devel] [Gluster-Maintainers] Gluster Test<br>
Thursday - Release 3.9<br>
Message-ID: <<a href="mailto:20161026181315.GC2936@ndevos-x240.usersys.redhat.com" target="_blank">20161026181315.GC2936@ndevos-<wbr>x240.usersys.redhat.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On Tue, Oct 25, 2016 at 01:11:26PM -0400, Kaleb S. KEITHLEY wrote:<br>
> On 10/25/2016 12:11 PM, Niels de Vos wrote:<br>
> > On Tue, Oct 25, 2016 at 07:51:47AM -0400, Kaleb S. KEITHLEY wrote:<br>
> >> On 10/25/2016 06:46 AM, Atin Mukherjee wrote:<br>
> >>><br>
> >>><br>
> >>> On Tue, Oct 25, 2016 at 4:12 PM, Aravinda <<a href="mailto:avishwan@redhat.com" target="_blank">avishwan@redhat.com</a><br>
> >>> <mailto:<a href="mailto:avishwan@redhat.com" target="_blank">avishwan@redhat.com</a>>> wrote:<br>
> >>><br>
> >>> Hi,<br>
> >>><br>
> >>> Since Automated test framework for Gluster is in progress, we need<br>
> >>> help from Maintainers and developers to test the features and bug<br>
> >>> fixes to release Gluster 3.9.<br>
> >>><br>
> >>> In last maintainers meeting Shyam shared an idea about having a Test<br>
> >>> day to accelerate the testing and release.<br>
> >>><br>
> >>> Please participate in testing your component(s) on Oct 27, 2016. We<br>
> >>> will prepare the rc2 build by tomorrow and share the details before<br>
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<wbr>^^^^^^^^^^<br>
> >>> Test day.<br>
> >>><br>
> >>> RC1 Link:<br>
> >>> <a href="http://www.gluster.org/pipermail/maintainers/2016-September/001442.html" rel="noreferrer" target="_blank">http://www.gluster.org/piperm<wbr>ail/maintainers/2016-September<wbr>/001442.html</a><br>
> >>> <<a href="http://www.gluster.org/pipermail/maintainers/2016-September/001442.html" rel="noreferrer" target="_blank">http://www.gluster.org/piper<wbr>mail/maintainers/2016-Septembe<wbr>r/001442.html</a>><br>
> >>><br>
> >>><br>
> >>> I don't think testing RC1 would be ideal as 3.9 head has moved forward<br>
> >>> with significant number of patches. I'd recommend of having an RC2 here.<br>
> >>><br>
> >><br>
> >> BTW, please tag RC2 as 3.9.0rc2 (versus 3.9rc2). It makes building<br>
> >> packages for Fedora much easier.<br>
> >><br>
> >> I know you were following what was done for 3.8rcX. That was a pain. :-}<br>
> ><br>
> > Can you explain what the problem is with 3.9rc2 and 3.9.0? The huge<br>
> > advantage is that 3.9.0 is seen as a version update to 3.9rc2. When<br>
> > 3.9.0rc2 is used, 3.9.0 is *not* an update for that, and rc2 packages<br>
> > will stay installed until 3.9.1 is released...<br>
> ><br>
> > You can check this easily with the rpmdev-vercmp command:<br>
> ><br>
> > $ rpmdev-vercmp 3.9.0rc2 3.9.0<br>
> > 3.9.0rc2 > 3.9.0<br>
> > $ rpmdev-vercmp 3.9rc2 3.9.0<br>
> > 3.9rc2 < 3.9.0<br>
><br>
> Those aren't really very realistic RPM NVRs IMO.<br>
><br>
> ><br>
> > So, at least for RPM packaging, 3.9rc2 is recommended, and 3.9.0rc2 is<br>
> > problematic.<br>
><br>
> That's not the only thing recommended.<br>
><br>
> Last I knew, one of several things that are recommended is, e.g.,<br>
> 3.9.0-0.2rc2; 3.9.0-1 > 3.9.0-0.2rc2.<br>
<br>
Yes, we can add a 0. in the release field of the RPMs. That works fine,<br>
but needs manual adoption of the .spec and is not done by the scripts we<br>
have that get called from 'make -C extras/LinuxRPM glusterrpms'. This<br>
means that RPMs build from the source (what developers do) and nightly<br>
builds need to be treated differently.<br>
<br>
> The RC (and {qa,alpha,beta}) packages (that I've) built for Fedora for<br>
> several years have had NVRs in that form.<br>
><br>
> This scheme was what was suggested to me on the fedora-devel mailing<br>
> list several years ago.<br>
<br>
Indeed, and this is common for Fedora packages. Maybe we should adapt<br>
that in our community RPMs too.<br>
<br>
> When RCs are tagged as 3.9rc1, then I have to make non-trivial and<br>
> counter-intuitive changes to the .spec file to build packages with NVRs<br>
> like 3.9.0-0.XrcY. If they are tagged 3.9.0rc1 then the changes much<br>
> more straight forward and much simpler.<br>
<br>
Yes, that is, if you want to have the 3.9.0 version, and do not like to<br>
take the 3.9rc2 version directly.<br>
<br>
We probably should address the pre-release tagging in our build scripts,<br>
so that the next release can easily be tagged v3.10.0rc1 or such.<br>
<br>
Thanks!<br>
Niels<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 801 bytes<br>
Desc: not available<br>
URL: <<a href="http://www.gluster.org/pipermail/gluster-devel/attachments/20161026/f2114f7b/attachment-0001.sig" rel="noreferrer" target="_blank">http://www.gluster.org/piperm<wbr>ail/gluster-devel/attachments/<wbr>20161026/f2114f7b/attachment-<wbr>0001.sig</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Wed, 26 Oct 2016 14:49:24 -0400<br>
From: "Kaleb S. KEITHLEY" <<a href="mailto:kkeithle@redhat.com" target="_blank">kkeithle@redhat.com</a>><br>
To: Gluster Devel <<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>>,<br>
<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a>, <a href="mailto:packaging@gluster.org" target="_blank">packaging@gluster.org</a><br>
Subject: Re: [Gluster-devel] [Gluster-Maintainers] glusterfs-3.9.0rc2<br>
released<br>
Message-ID: <<a href="mailto:390562a6-99b7-624f-cd83-b8ba49cdaddf@redhat.com" target="_blank">390562a6-99b7-624f-cd83-b8ba4<wbr>9cdaddf@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On 10/26/2016 10:29 AM, Gluster Build System wrote:<br>
><br>
><br>
> SRC: <a href="http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.9.0rc2.tar.gz" rel="noreferrer" target="_blank">http://bits.gluster.org/pub/gl<wbr>uster/glusterfs/src/glusterfs-<wbr>3.9.0rc2.tar.gz</a><br>
><br>
<br>
WRT GlusterFS 3.9.0rc2 testing day tomorrow (Thursday, 27 October):<br>
<br>
There are packages for Fedora 23, 24, 25; and EPEL 6 and 7 at [1].<br>
<br>
There are also packages for Fedora 26 (rawhide) in Fedora Updates.<br>
<br>
I will try to get packages for Debian 8 (jessie) by tomorrow. They will<br>
be at the same location. I may also try to get Ubuntu packages. If I do<br>
I will announce the location, i.e. they may be somewhere else, e.g.<br>
launchpad.<br>
<br>
[1] <a href="https://download.gluster.org/pub/gluster/glusterfs/3.9/3.9.0rc2/" rel="noreferrer" target="_blank">https://download.gluster.org/p<wbr>ub/gluster/glusterfs/3.9/3.9.0<wbr>rc2/</a><br>
<br>
--<br>
<br>
Kaleb<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Thu, 27 Oct 2016 08:30:07 +0530<br>
From: Pranith Kumar Karampuri <<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>><br>
To: Gluster Devel <<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>><br>
Subject: [Gluster-devel] automating straightforward backports<br>
Message-ID:<br>
<CAOgeEnaen8OS4K=-<a href="mailto:fE20PL-VBcJSKBmgpUGzTFuyU7B39zJidg@mail.gmail.com" target="_blank">fE20PL-VBcJS<wbr>KBmgpUGzTFuyU7B39zJidg@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
hi,<br>
Nowadays I am seeing quite a few patches are straightforward backports<br>
from master. But if I follow the process it generally takes around 10<br>
minutes to complete porting each patch. I was wondering if anyone else<br>
looked into automating this. Yesterday I had to backport<br>
<a href="http://review.gluster.org/15728" rel="noreferrer" target="_blank">http://review.gluster.org/1572<wbr>8</a> to 3.9, 3.8, 3.7. So I finally took some<br>
time to automate portions of the workflow. I want to exchange ideas you may<br>
be using to achieve the same.<br>
<br>
Here is how I automated portions:<br>
1) Cloning bug to different branches:<br>
Not automated: It seems like bugzilla CLI doesn't allow cloning of the<br>
bug :-(. Anyone knows if we can write a script which interacts with the<br>
website to achieve this?<br>
<br>
2) Porting the patch to the branches: Wrote the following script which will<br>
do the porting adding prefix " >" to the commit-headers<br>
==============================<wbr>=====================<br>
? cat ../backport.sh<br>
#!/bin/bash<br>
#launch it like this: BRANCHES="3.9 3.8 3.7" ./backport.sh<br>
<branch-name-prefix> <commit-hash-to-be-backported><br>
<br>
prefix=$1<br>
shift<br>
commit=$1<br>
shift<br>
<br>
function add_prefix_to_commit_headers {<br>
#We have the habit of adding ' >' for the commit headers<br>
for i in BUG Change-Id Signed-off-by Reviewed-on Smoke<br>
NetBSD-regression Reviewed-by CentOS-regression; do sed -i -e "s/^$i:/<br>
>$i:/" commit-msg; done<br>
}<br>
<br>
function form_commit_msg {<br>
#Get the commit message out of the commit<br>
local commit=$1<br>
git log --format=%B -n 1 $commit > commit-msg<br>
}<br>
<br>
function main {<br>
cur_branch=$(git rev-parse --abbrev-ref HEAD)<br>
form_commit_msg $commit<br>
add_prefix_to_commit_headers;<br>
rm -f branches;<br>
for i in $BRANCHES; do cp commit-msg ${i}-commit-msg && git<br>
checkout -b ${prefix}-${i} origin/release-${i} > /dev/null && git<br>
cherry-pick $commit && git commit -s --amend -F ${i}-commit-msg && echo<br>
${prefix}-${i} >> branches; done<br>
git checkout $cur_branch<br>
}<br>
<br>
main<br>
==============================<wbr>=====================<br>
<br>
3) Adding reviewers, triggering regressions, smoke:<br>
I have been looking around for good gerrit-cli, at the moment, I am<br>
happy with the gerrit CLI which is installed through npm. So you need to<br>
first install npm on your box and then do 'npm install gerrit'<br>
Go to the branch from where we did the commit and do:<br>
# gerrit assign <a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a> - this will add Xavi as<br>
reviewer for the patch that I just committed.<br>
# gerrit comment "recheck smoke"<br>
# gerrit comment "recheck centos"<br>
# gerrit comment "recheck netbsd"<br>
<br>
4) I am yet to look into bugzilla cli to come up with the command to move<br>
the bugs into POST, but may be Niels has it at his fingertips?<br>
<br>
Main pain point has been cloning the bugs. If we have an automated way to<br>
clone the bug to different branches. The script at 2) can be modified to<br>
add all the steps.<br>
If we can clone the bug and get the bz of the cloned bug, then we can add<br>
"BUG: <bz>" to the commit-message and launch rfc.sh which won't prompt for<br>
anything. We can auto answer coding-guidelines script by launching "yes |<br>
rfc.sh" if we really want to.<br>
<br>
PS: The script is something I hacked together for one time use yesterday.<br>
Not something I guessed I would send a mail about today so it is not all<br>
that good looking. Just got the job done yesterday.<br>
<br>
--<br>
Pranith<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://www.gluster.org/pipermail/gluster-devel/attachments/20161027/948757a8/attachment.html" rel="noreferrer" target="_blank">http://www.gluster.org/piperm<wbr>ail/gluster-devel/attachments/<wbr>20161027/948757a8/attachment.<wbr>html</a>><br>
<br>
------------------------------<br>
<br>
______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman<wbr>/listinfo/gluster-devel</a><br>
<br>
End of Gluster-devel Digest, Vol 31, Issue 61<br>
******************************<wbr>***************<br>
</blockquote></div><br></div></div>