[Gluster-infra] Nightly regression job with enabling brick multiplexing
Niels de Vos
ndevos at redhat.com
Tue Apr 25 17:19:32 UTC 2017
On Tue, Apr 25, 2017 at 12:50:45PM -0400, Jeff Darcy wrote:
> On Mon, Apr 24, 2017, at 11:52 AM, Jeff Darcy wrote:
> > On Fri, Apr 21, 2017, at 09:17 AM, Atin Mukherjee wrote:
> >> As we don't run our .t files with brick mux being enabled for every
> >> patches can we ensure that there is a nightly regression trigger with
> >> brick multiplexing feature being enabled. The reason for this ask is
> >> very simple, we have no control on the regression for this feature.
> >> I've already seen a very basic test (volume status not reflecting
> >> bricks online after glusterd restart) breaking recently which used to
> >> work earlier.>
> > +100
> FWIW, the way I ran these tests during development was to have a patch
> that makes multiplexing the default. I'd periodically rebase that on
> top of whatever else was current, then run regressions on that. To do
> that as part of a periodic test, we'd need the regression scripts to
> look for that same patch in some "well known place" and apply it before
> building. Is that something that somebody else would feel comfortable
> implementing, or should I look into it?
This "well known place" could be a branch in the git repository, maybe
with an obvious name like "for-testing/brick-multiplex". In case the
patch needs changing, everyone could then just update it and send a
review. Maybe it is even possible to automatically rebase the
"for-testing" branch every now and then.
A Jenkins job can then checkout the master branch, and merge the
"for-testing" branch before running the tests.
Or, we have a change on review.gluster.org that never gets merged, and
gets cherry-picked before running the regression tests (probably
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: not available
More information about the Gluster-infra